Re: [PATCH 0/3] fs/sysv: stop using write_supers and s_dirt
On Fri, 2012-07-13 at 14:42 -0700, Andrew Morton wrote: The issue Alan raised around the superblock timestamp is still up in the air. I guess he's a slow typist ;) My take is no, we don't need to do that any more - surely all Linux systems have a functional hardware clock. But the changelog should be updated to describe and justify the decision. While I do trust such system existed and may be even still exist, I doubt that Linux sysv FS implementation is of any help for them because it updates the superblock time-stamp _only_ if there was write activity, otherwise it does not. So you cannot rely on our time-stamps at all anyway. My patches just make it update the time-stamp more rarely. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH v3 1/2] vsyscall: allow seccomp in vsyscall=emulate
If a seccomp filter program is installed, older static binaries and
distributions with older libc implementations (glibc 2.13 and earlier)
that rely on vsyscall use will be terminated regardless of the filter
program policy when executing time, gettimeofday, or getcpu. This is
only the case when vsyscall emulation is in use (vsyscall=emulate is the
default).
This patch emulates system call entry inside a vsyscall=emulate by
populating regs-ax and regs-orig_ax with the system call number prior
to calling into seccomp such that all seccomp-dependencies function
normally. Additionally, system call return behavior is emulated in line
with other vsyscall entrypoints for the trace/trap cases.
Note, v3 adds support for a ptracer to skip and emulate vsyscalls. This
is not required behavior but the documentation should reflect the behavior
for whichever is preferred (v2 or v3).
Reported-by: Owen Kibel qme...@gmail.com
Signed-off-by: Will Drewry w...@chromium.org
v3: - allow ptrace orig_ax changes to skip the syscall since changing it is not
an option. (result of discussions with luto)
- ensure ptrace register modification doesn't change return behavior taking
the normal return path
- add some comments
v2: - fixed ip and sp on SECCOMP_RET_TRAP/ERRNO (thanks to l...@mit.edu)
---
arch/x86/kernel/vsyscall_64.c | 42 +
1 file changed, 38 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 7515cf0..c56a8dc 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -139,6 +139,22 @@ static int addr_to_vsyscall_nr(unsigned long addr)
return nr;
}
+static int vsyscall_seccomp(struct task_struct *tsk, int syscall_nr)
+{
+ int ret;
+ struct pt_regs *regs;
+ if (!seccomp_mode(tsk-seccomp))
+ return 0;
+ regs = task_pt_regs(tsk);
+ regs-orig_ax = syscall_nr;
+ regs-ax = syscall_nr; /* ensure consistency */
+ /* 0 if allowed, -1 on SECCOMP_RET_ERRNO and SECCOMP_RET_TRAP */
+ ret = __secure_computing(syscall_nr);
+ if (regs-orig_ax != syscall_nr)
+ return 1; /* ptrace requested skip */
+ return ret;
+}
+
static bool write_ok_or_segv(unsigned long ptr, size_t size)
{
/*
@@ -174,6 +190,7 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
int vsyscall_nr;
int prev_sig_on_uaccess_error;
long ret;
+ int skip;
/*
* No point in checking CS -- the only way to get here is a user mode
@@ -205,9 +222,6 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
}
tsk = current;
- if (seccomp_mode(tsk-seccomp))
- do_exit(SIGKILL);
-
/*
* With a real vsyscall, page faults cause SIGSEGV. We want to
* preserve that behavior to make writing exploits harder.
@@ -222,8 +236,13 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
* address 0.
*/
ret = -EFAULT;
+ skip = 0;
switch (vsyscall_nr) {
case 0:
+ skip = vsyscall_seccomp(tsk, __NR_gettimeofday);
+ if (skip)
+ break;
+
if (!write_ok_or_segv(regs-di, sizeof(struct timeval)) ||
!write_ok_or_segv(regs-si, sizeof(struct timezone)))
break;
@@ -234,6 +253,10 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
break;
case 1:
+ skip = vsyscall_seccomp(tsk, __NR_time);
+ if (skip)
+ break;
+
if (!write_ok_or_segv(regs-di, sizeof(time_t)))
break;
@@ -241,6 +264,10 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
break;
case 2:
+ skip = vsyscall_seccomp(tsk, __NR_getcpu);
+ if (skip)
+ break;
+
if (!write_ok_or_segv(regs-di, sizeof(unsigned)) ||
!write_ok_or_segv(regs-si, sizeof(unsigned)))
break;
@@ -253,6 +280,12 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
current_thread_info()-sig_on_uaccess_error = prev_sig_on_uaccess_error;
+ if (skip) {
+ if ((long)regs-ax = 0L || skip == 1) /* seccomp errno/trace */
+ goto do_ret;
+ goto done; /* seccomp trap */
+ }
+
if (ret == -EFAULT) {
/* Bad news -- userspace fed a bad pointer to a vsyscall. */
warn_bad_vsyscall(KERN_INFO, regs,
@@ -271,10 +304,11 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
regs-ax = ret;
+do_ret:
/* Emulate a ret instruction. */
regs-ip = caller;
regs-sp += 8;
-
+done:
[PATCH v3 2/2] Documentation: add a caveat for seccomp filter and vsyscall emulation
With the addition of seccomp support to vsyscall emulation: http://permalink.gmane.org/gmane.linux.kernel/1327732 with some minor changes in the first patch in this series. Update the documentation to indicate quirky behaviors when the 'ip' is in the vsyscall page and vsyscall emulation is in effect. If v2 of the first patch is preferred, then this patch will need to be changed to indicate that SECCOMP_RET_TRACE does not allow system calls to be remapped _or_ skipped. Signed-off-by: Will Drewry w...@chromium.org --- Documentation/prctl/seccomp_filter.txt | 22 ++ 1 file changed, 22 insertions(+) diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt index 597c3c5..67ed88b 100644 --- a/Documentation/prctl/seccomp_filter.txt +++ b/Documentation/prctl/seccomp_filter.txt @@ -161,3 +161,25 @@ architecture supports both ptrace_event and seccomp, it will be able to support seccomp filter with minor fixup: SIGSYS support and seccomp return value checking. Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER to its arch-specific Kconfig. + + +Caveats +--- + +On x86-64 with vsyscall emulation enabled and while servicing a +vsyscall-emulated system call: +- A return value of SECCOMP_RET_TRAP will set a si_call_addr pointing to + the vsyscall entry for the given call and not the address after the + 'syscall' instruction. Any code which wants to restart the call + should return to that address and code wishing to return simulating + completion may either sigreturn normally or simulate a ret instruction + and use the return address from the stack. +- A return value of SECCOMP_RET_TRACE will signal the tracer as usual, + but the syscall may not be changed to another system call using the + orig_rax register. It may only be changed to a different value in + order to skip the currently emulated call and any change will result + in that behavior. The remainder of the registers may be altered as + usual. +- Detection of this quirky behavior may be done by checking for getcpu, + time, or gettimeofday and if the si_call_addr or rip is in the + vsyscall page, specifically at the start of the specific entry call. -- 1.7.9.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: [RFC] Simplifying kernel configuration for distro issues
On Fri, 2012-07-13 at 13:37 -0700, Linus Torvalds wrote: So this has long been one of my pet configuration peeves: as a user I am perfectly happy answering the questions about what kinds of hardware I want the kernel to support (I kind of know that), but many of the support infrastructure questions are very opaque, and I have no idea which of the them any particular distribution actually depends on. [...] The point I'm slowly getting to is that I would actually love to have *distro* Kconfig-files, where the distribution would be able to say These are the minimums I *require* to work. So we'd have a Distro submenu, where you could pick the distro(s) you use, and then pick which release, and we'd have something like I like this idea in principle. [...] - distro/Kconfig: config DISTRO_REQUIREMENTS bool Pick minimal distribution requirements choice DISTRO prompt Distribution depends on DISTRO_REQUIREMENTS config FEDORA config OPENSUSE config UBUNTU ... endchoice and then depending on the DISTRO config, we'd include one of the distro-specific ones with lists of supported distro versions and then the random config settings for that version: You might also want to *un*select some options like CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2 that need to be set one way or the other depending on the version of udev. (I think it's possible to kluge this with the addition of a hidden negative config option.) How about stuff like NET and INET, that every distro will need and yet is configurable even without EXPERT? [...] Sure, you can copy the config file that came with the distro, but it has tons of stuff that really isn't required. Not just in hardware, but all the debug choices etc that are really a user choice. And it's really hard to figure out - even for somebody like me - what a minimal usable kernel is. [...] And it's still hard for me as kernel packager: just because an option was requested and enabled to support some bit of userland, doesn't mean I know what's using or depending on it now. (I think Dave Jones made this point already.) I'm not usually concerned with *minimal* config. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Re: [PATCH] bnx2: update bnx2-mips-09 firmware to bnx2-mips-09-6.2.1b
On Fri, 2012-07-13 at 15:09 +0100, Chris Webb wrote: Eric Dumazet eric.duma...@gmail.com writes: Have you read firmware/README.AddingFirmware ? I hadn't, but now I have, and if firmware upgrades are considered 'adding new firmware', I agree this patch is wrong, and should have just removed the obsolete bnx2-mips-09-6.2.1a file that is no longer used by the bnx2 driver. However, not having dealt with cards that need these kinds of horrible binary blobs before, I'm a little uncertain how I should be building upstream kernels with CONFIG_FIRMWARE_IN_KERNEL and pulling in the correct blobs from a linux-firmware checkout. Is there a more automatic method than going through the source for each configured driver and setting CONFIG_EXTRA_FIRMWARE manually to list the relevant firmwares? Is there any way to give the kernel the location of linux-firmware and have it compile in everything needed for the selected drivers, as used to happen with the firmware/ subdirectory? CONFIG_EXTRA_FIRMWARE_DIR doesn't seem to do anything with CONFIG_EXTRA_FIRMWARE empty, so I don't think it does what I'm hoping? I had a go at making CONFIG_FIRMWARE_IN_KERNEL pick the right blobs automatically http://thread.gmane.org/gmane.linux.kernel/1230462, but I couldn't get the Kbuild rules quite right. No-one responded and I haven't had another try since. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Re: [PATCH 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
Seeing code like this
+ return (*nr_running)[0];
just makes me go WTF?
Why are you taking the address of something you just dereferenced (the
[0] part).
And you actually do that *twice*, except the inner one is more
complicated. When you assign nr_runing, you take the address of it, so
the *nr_running is actually just the same kind of odd thing (except
in reverse - you take dereference something you just took the
address-of).
Seriously, this to me is a sign of *deeply* confused code. And the
fact that your first version of that code was buggy *EXACTLY* due to
this confusion should have made you take a step back.
As far as I can tell, what you actually want that function to do is:
static atomic_t *get_pool_nr_running(struct worker_pool *pool)
{
int cpu = pool-gcwq-cpu;
if (cpu != WORK_CPU_UNBOUND)
return per_cpu(pool_nr_running, cpu);
return unbound_pool_nr_running;
}
Notice how there isn't an 'address-of' operator anywhere in sight
there. Those things are arrays, they get turned into atomic_t *
automatically. And there isn't a single dereference (not a '*', and
not a [0] - they are the exact same thing, btw) in sight either.
What am I missing? Are there some new drugs that all the cool kids
chew that I should be trying? Because I really don't think the kinds
of insane take the address of a dereference games are a good idea.
They really look to me like somebody is having a really bad drug
experience.
I didn't test the code, btw. I just looked at the patch and went WTF.
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: [PATCH 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
Hello, Linus.
On Fri, Jul 13, 2012 at 09:27:03PM -0700, Linus Torvalds wrote:
Seeing code like this
+ return (*nr_running)[0];
just makes me go WTF?
I was going WTF too. This was the smallest fix and I wanted to make
it minimal because there's another stack of patches on top of it.
Planning to just fold nr_running into worker_pool afterwards which
will remove the whole function.
Why are you taking the address of something you just dereferenced (the
[0] part).
nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to
array part, it's just returning the address of N'th element of the
array. ARRAY + N == ARRAY[N].
And you actually do that *twice*, except the inner one is more
complicated. When you assign nr_runing, you take the address of it, so
the *nr_running is actually just the same kind of odd thing (except
in reverse - you take dereference something you just took the
address-of).
Seriously, this to me is a sign of *deeply* confused code. And the
fact that your first version of that code was buggy *EXACTLY* due to
this confusion should have made you take a step back.
Type-wise, I don't think it's confused. Ah okay, you're looking at
the fifth patch in isolation. Upto this point, the index is always 0.
I'm puttin it in as a placeholder for the next patch which makes use
of non-zero index. This patch is supposed to prepare everything for
multiple pools and thus non-zero index.
As far as I can tell, what you actually want that function to do is:
static atomic_t *get_pool_nr_running(struct worker_pool *pool)
{
int cpu = pool-gcwq-cpu;
if (cpu != WORK_CPU_UNBOUND)
return per_cpu(pool_nr_running, cpu);
return unbound_pool_nr_running;
}
More like the folloiwng in the end.
static atomic_t *get_pool_nr_running(struct worker_pool *pool)
{
int cpu = pool-gcwq-cpu;
int is_highpri = pool_is_highpri(pool);
if (cpu != WORK_CPU_UNBOUND)
return per_cpu(pool_nr_running, cpu)[is_highpri];
return unbound_pool_nr_running[is_highpri];
}
I didn't test the code, btw. I just looked at the patch and went WTF.
Eh... yeah, with or without [2], this is WTF. I'll just refresh it
with the above version.
Thanks.
--
tejun
--
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: [RESEND PATCH 1/1] clk: add DT support for clock gating control
On 07/13/2012 04:42 AM, Sebastian Hesselbarh wrote:
On 07/13/2012 05:19 AM, Rob Herring wrote:
What's implemented in Linux should not define the binding. The binding
should describe the hardware.
[...]
True, but not your problem to implement. A binding doesn't necessarily
mean there is a full Linux implementation. We just don't want to create
something only to find others need something completely different.
Ok, what about a DT describing the following for a simple register-based
clock gating controller and the corresponding gated-clock independent of
the controller. I am sure there are a bunch of SoCs out there that
control their clock gates by writing some bits to a register. If that
DT description matches your expectations, I ll prepare patches with
documentation and implementation for common clock framework.
Clock gates are just 1 part. There's muxes, dividers, plls, etc. I'm not
convinced that it makes sense to define clocks at this level. For
complex chips, I think just defining the chips clock controller module
as a single node with lots of clock outputs. The primary need is to
describe board specific changes not SOC level clock tree. Much of it is
static and generally only a few clocks may change config board to board.
Sebastian
--
/* Simple clock gating controller based on bitmasks and register */
cgc: clock-gating-control@f100 {
compatible = clock-gating-control-register;
reg = 0xf100 0x4;
/* Clock gating control with one bit at bit position 0
enable with (10), disable with (00) */
cgctrl_usb0: cgc_usb0 {
clock-gating-control,shift = 0;
clock-gating-control,mask = 1;
clock-gating-control,enable = 1;
clock-gating-control,disable = 0;
};
/* Clock gating control with two bits at bit position 1-2
enable with (21), disable with (01) */
cgctrl_sata: cgc_sata {
clock-gating-control,shift = 1;
clock-gating-control,mask = 3;
clock-gating-control,enable = 2;
clock-gating-control,disable = 0;
};
};
/* Generic clock gate description that can be used with
any clock gating controller */
cg_usb0: clockgate@0 {
compatible = gated-clock;
#clock-cells = 0;
clocks = osc;
clock-gate-control = cgctrl_usb0;
};
I don't see this scaling to ~50 clocks.
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/
Re: [PATCH 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo t...@kernel.org wrote: nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to array part, it's just returning the address of N'th element of the array. ARRAY + N == ARRAY[N]. None of this matters one whit. You did (x)[0]. That's insane. It's crazy. It doesn't even matter what x is in between, it's crazy regardless. It's just a really confused way of saying x (*). Except it makes the code look like an insane monkey on crack got a-hold of your keyboard when you weren't looking. And to make it worse, x itself was the result of doing *y. Which was probably written by the insane monkey's older brother, Max, who has been chewing Quaaludes for a few years, and as a result _his_ brain really isn't doing too well either. Even for a monkey. And now you're letting *him* at your keyboard too? So you had two separately (but similarly) insane ways of complicating the code so that it was really obfuscated. When it really just computed y to begin with, it just added all those x=*y and (x)[0] games around it to make it look complicated. Linus (*) Technically, (x)[0] is actually a really confused way of saying (x+0) while making sure that x was a valid pointer. It basically guarantees that if x started out as an array, it has now been demoted to a pointer - but since arrays will be demoted to pointers by pretty much any subsequent operation except for sizeof() and a couple of other special cases anyway, you can pretty much just say that (x)[0] is (x+0) is x. And *y really is exactly the same as y, except for again some syntactic checking (ie it is basically an odd way to verify that y is an lvalue, since you cannot do an address-of of a non-lvalue). -- 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: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot
On 13/07/2012 21:20, Olaf Hering o...@aepfle.de wrote: On Tue, Jul 10, Keir Fraser wrote: On 10/07/2012 19:09, Olaf Hering o...@aepfle.de wrote: I'm not sure, most likely the gfn will just disappear from the guest, like a ballooned page disappears. Accessing it will likely cause a crash. Best thing to do, is possible, is map the shared-info page in the xen-platform pci device's BAR memory range. Then it will not conflict with any RAM. If you do map it over the top of an existing RAM page, you will have to repopulate that RAM page before kexec, using populate_physmap hypercall. The good news is that the populate_physmap hypercall will have the side effect of unmapping the shared-info page, reayd to be mapped wherever the new kernel would like it to reside :) Keir, is this a safe thing to do in a SMP guest? If arch/x86/xen/enlighten.c:xen_hvm_init_shared_info() allocates a page (backed by mfn M and pfn A) and assigns *HYPERVISOR_shared_info and *xen_vcpu then everything will reference these pointers. So pfn A now points at shared_info, and mfn M is lost (freed back to Xen). Xen_vcpu doesn't come into it, you'd have that mapped at yet another pfn. If drivers/xen/platform-pci.c:platform_pci_init would also do a XENMAPSPACE_shared_info call with pfn B, isnt there a small window where pfn A is not backed by a mfn because mfn M is now connected to pfn C? As a result other code paths which access *HYPERVISOR_shared_info and *xen_vcpu between the hypercall and the update of the pointers will read 0xff. Don't really understand this. After the XENMAPSPACE_shared_info_call: * PFN B points at shared_info, mfn M_B it previously mapped is lost (freed back to Xen). * PFN A maps nothing, reads return all-1s. Yes, obviously you can't atomically update the mapping of shinfo from A-B, ad update your pointer in the kernel at exactly the same time. Presumably you do this early during boot, or late during kexec, or otherwise at a time when other processors are not expected to touch shinfo. If I read the hypercall code of XENMEM_add_to_physmap correctly the mfn backing *HYPERVISOR_shared_info will remain the same, so there is no need to copy data from the old to the new *HYPERVISOR_shared_info. That is correct. What do you think, is that race real? I suppose it is. I didn't imagine it would be a troublesome one though. -- Keir Olaf -- 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 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
Hey, Linus. On Fri, Jul 13, 2012 at 10:00:10PM -0700, Linus Torvalds wrote: On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo t...@kernel.org wrote: nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to array part, it's just returning the address of N'th element of the array. ARRAY + N == ARRAY[N]. None of this matters one whit. You did (x)[0]. That's insane. It's crazy. It doesn't even matter what x is in between, it's crazy regardless. Eh, from my previous reply. | Ah okay, you're looking at the fifth patch in isolation. Upto this | point, the index is always 0. I'm puttin it in as a placeholder for | the next patch which makes use of non-zero index. This patch is | supposed to prepare everything for multiple pools and thus non-zero | index. The patch is about converting stuff to handle size-1 array without introducing any actual behavior change so that the next patch can bump the array size and just change the index. Thanks. -- tejun -- 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: general protection fault on ttm_init()
Hi Dave, On Sat, Jul 14, 2012 at 01:33:45PM +1000, Dave Airlie wrote: Can you try this patch on top of the previous one? I think it should fix it. You are right, it works! Thank you very much! :-) Thanks, Fengguang -- 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 UPDATED 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
From 4ce62e9e30cacc26885cab133ad1de358dd79f21 Mon Sep 17 00:00:00 2001
From: Tejun Heo t...@kernel.org
Date: Fri, 13 Jul 2012 22:16:44 -0700
Introduce NR_WORKER_POOLS and for_each_worker_pool() and convert code
paths which need to manipulate all pools in a gcwq to use them.
NR_WORKER_POOLS is currently one and for_each_worker_pool() iterates
over only @gcwq-pool.
Note that nr_running is per-pool property and converted to an array
with NR_WORKER_POOLS elements and renamed to pool_nr_running. Note
that get_pool_nr_running() currently assumes 0 index. The next patch
will make use of non-zero index.
The changes in this patch are mechanical and don't caues any
functional difference. This is to prepare for multiple pools per
gcwq.
v2: nr_running indexing bug in get_pool_nr_running() fixed.
v3: Pointer to array is stupid. Don't use it in get_pool_nr_running()
as suggested by Linus.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fengguang Wu fengguang...@intel.com
Cc: Linus Torvalds torva...@linux-foundation.org
---
So, the same 0 index silliness but this shouldn't be as fugly.
Thanks.
kernel/workqueue.c | 223 +++
1 files changed, 153 insertions(+), 70 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7a98bae..b0daaea 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -74,6 +74,8 @@ enum {
TRUSTEE_RELEASE = 3,/* release workers */
TRUSTEE_DONE= 4,/* trustee is done */
+ NR_WORKER_POOLS = 1,/* # worker pools per gcwq */
+
BUSY_WORKER_HASH_ORDER = 6,/* 64 pointers */
BUSY_WORKER_HASH_SIZE = 1 BUSY_WORKER_HASH_ORDER,
BUSY_WORKER_HASH_MASK = BUSY_WORKER_HASH_SIZE - 1,
@@ -274,6 +276,9 @@ EXPORT_SYMBOL_GPL(system_nrt_freezable_wq);
#define CREATE_TRACE_POINTS
#include trace/events/workqueue.h
+#define for_each_worker_pool(pool, gcwq) \
+ for ((pool) = (gcwq)-pool; (pool); (pool) = NULL)
+
#define for_each_busy_worker(worker, i, pos, gcwq) \
for (i = 0; i BUSY_WORKER_HASH_SIZE; i++) \
hlist_for_each_entry(worker, pos, gcwq-busy_hash[i], hentry)
@@ -454,7 +459,7 @@ static bool workqueue_freezing; /* W: have wqs
started freezing? */
* try_to_wake_up(). Put it in a separate cacheline.
*/
static DEFINE_PER_CPU(struct global_cwq, global_cwq);
-static DEFINE_PER_CPU_SHARED_ALIGNED(atomic_t, gcwq_nr_running);
+static DEFINE_PER_CPU_SHARED_ALIGNED(atomic_t,
pool_nr_running[NR_WORKER_POOLS]);
/*
* Global cpu workqueue and nr_running counter for unbound gcwq. The
@@ -462,7 +467,9 @@ static DEFINE_PER_CPU_SHARED_ALIGNED(atomic_t,
gcwq_nr_running);
* workers have WORKER_UNBOUND set.
*/
static struct global_cwq unbound_global_cwq;
-static atomic_t unbound_gcwq_nr_running = ATOMIC_INIT(0); /* always 0 */
+static atomic_t unbound_pool_nr_running[NR_WORKER_POOLS] = {
+ [0 ... NR_WORKER_POOLS - 1] = ATOMIC_INIT(0), /* always 0 */
+};
static int worker_thread(void *__worker);
@@ -477,11 +484,12 @@ static struct global_cwq *get_gcwq(unsigned int cpu)
static atomic_t *get_pool_nr_running(struct worker_pool *pool)
{
int cpu = pool-gcwq-cpu;
+ int idx = 0;
if (cpu != WORK_CPU_UNBOUND)
- return per_cpu(gcwq_nr_running, cpu);
+ return per_cpu(pool_nr_running, cpu)[idx];
else
- return unbound_gcwq_nr_running;
+ return unbound_pool_nr_running[idx];
}
static struct cpu_workqueue_struct *get_cwq(unsigned int cpu,
@@ -3345,9 +3353,30 @@ EXPORT_SYMBOL_GPL(work_busy);
__ret1 0 ? -1 : 0;\
})
+static bool gcwq_is_managing_workers(struct global_cwq *gcwq)
+{
+ struct worker_pool *pool;
+
+ for_each_worker_pool(pool, gcwq)
+ if (pool-flags POOL_MANAGING_WORKERS)
+ return true;
+ return false;
+}
+
+static bool gcwq_has_idle_workers(struct global_cwq *gcwq)
+{
+ struct worker_pool *pool;
+
+ for_each_worker_pool(pool, gcwq)
+ if (!list_empty(pool-idle_list))
+ return true;
+ return false;
+}
+
static int __cpuinit trustee_thread(void *__gcwq)
{
struct global_cwq *gcwq = __gcwq;
+ struct worker_pool *pool;
struct worker *worker;
struct work_struct *work;
struct hlist_node *pos;
@@ -3363,13 +3392,15 @@ static int __cpuinit trustee_thread(void *__gcwq)
* cancelled.
*/
BUG_ON(gcwq-cpu != smp_processor_id());
- rc = trustee_wait_event(!(gcwq-pool.flags POOL_MANAGING_WORKERS));
+ rc = trustee_wait_event(!gcwq_is_managing_workers(gcwq));
BUG_ON(rc 0);
- gcwq-pool.flags |= POOL_MANAGING_WORKERS;
+
[PATCH UPDATED v3 6/6] workqueue: reimplement WQ_HIGHPRI using a separate worker_pool
From a465fcee388d62d22e390b57c81ca8411f25a1da Mon Sep 17 00:00:00 2001 From: Tejun Heo t...@kernel.org Date: Fri, 13 Jul 2012 22:16:45 -0700 WQ_HIGHPRI was implemented by queueing highpri work items at the head of the global worklist. Other than queueing at the head, they weren't handled differently; unfortunately, this could lead to execution latency of a few seconds on heavily loaded systems. Now that workqueue code has been updated to deal with multiple worker_pools per global_cwq, this patch reimplements WQ_HIGHPRI using a separate worker_pool. NR_WORKER_POOLS is bumped to two and gcwq-pools[0] is used for normal pri work items and -pools[1] for highpri. Highpri workers get -20 nice level and has 'H' suffix in their names. Note that this change increases the number of kworkers per cpu. POOL_HIGHPRI_PENDING, pool_determine_ins_pos() and highpri chain wakeup code in process_one_work() are no longer used and removed. This allows proper prioritization of highpri work items and removes high execution latency of highpri work items. v2: nr_running indexing bug in get_pool_nr_running() fixed. v3: Refreshed for the get_pool_nr_running() update in the previous patch. Signed-off-by: Tejun Heo t...@kernel.org Reported-by: Josh Hunt joshhun...@gmail.com LKML-Reference: CAKA=qzahqwz8eqplnfjxno2fx-tgaojmpvxgbfjv6djeqao...@mail.gmail.com Cc: Tony Luck tony.l...@intel.com Cc: Fengguang Wu fengguang...@intel.com --- Documentation/workqueue.txt | 103 --- kernel/workqueue.c | 100 +++-- 2 files changed, 65 insertions(+), 138 deletions(-) diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index a0b577d..a6ab4b6 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt @@ -89,25 +89,28 @@ called thread-pools. The cmwq design differentiates between the user-facing workqueues that subsystems and drivers queue work items on and the backend mechanism -which manages thread-pool and processes the queued work items. +which manages thread-pools and processes the queued work items. The backend is called gcwq. There is one gcwq for each possible CPU -and one gcwq to serve work items queued on unbound workqueues. +and one gcwq to serve work items queued on unbound workqueues. Each +gcwq has two thread-pools - one for normal work items and the other +for high priority ones. Subsystems and drivers can create and queue work items through special workqueue API functions as they see fit. They can influence some aspects of the way the work items are executed by setting flags on the workqueue they are putting the work item on. These flags include -things like CPU locality, reentrancy, concurrency limits and more. To -get a detailed overview refer to the API description of +things like CPU locality, reentrancy, concurrency limits, priority and +more. To get a detailed overview refer to the API description of alloc_workqueue() below. -When a work item is queued to a workqueue, the target gcwq is -determined according to the queue parameters and workqueue attributes -and appended on the shared worklist of the gcwq. For example, unless -specifically overridden, a work item of a bound workqueue will be -queued on the worklist of exactly that gcwq that is associated to the -CPU the issuer is running on. +When a work item is queued to a workqueue, the target gcwq and +thread-pool is determined according to the queue parameters and +workqueue attributes and appended on the shared worklist of the +thread-pool. For example, unless specifically overridden, a work item +of a bound workqueue will be queued on the worklist of either normal +or highpri thread-pool of the gcwq that is associated to the CPU the +issuer is running on. For any worker pool implementation, managing the concurrency level (how many execution contexts are active) is an important issue. cmwq @@ -115,26 +118,26 @@ tries to keep the concurrency at a minimal but sufficient level. Minimal to save resources and sufficient in that the system is used at its full capacity. -Each gcwq bound to an actual CPU implements concurrency management by -hooking into the scheduler. The gcwq is notified whenever an active -worker wakes up or sleeps and keeps track of the number of the -currently runnable workers. Generally, work items are not expected to -hog a CPU and consume many cycles. That means maintaining just enough -concurrency to prevent work processing from stalling should be -optimal. As long as there are one or more runnable workers on the -CPU, the gcwq doesn't start execution of a new work, but, when the -last running worker goes to sleep, it immediately schedules a new -worker so that the CPU doesn't sit idle while there are pending work -items. This allows using a minimal number of workers without losing -execution bandwidth. +Each thread-pool bound to an actual CPU implements concurrency +management by
[PATCH RFT 1/2] regulator: twl: Fix checking voltage range in twl6030smps_set_voltage()
The voltage selection logic is supposed to find the samllest voltage falls
within specified range. When using equation to calculate vsel, we need to
ensure the requested min_uV meet the range of using the equation.
Otherwise we may select a voltage that is out of specified range.
For example, in the case vsel = 62 means select voltage of 210uV.
What we want is to ensure the requested min_uV = 210 rather than checking
max_uV = 210. And this also means in the case min_uV 210, vsel = 62
does not meet the request.
Also calling twl6030smps_list_voltage() for all cases to ensure the selected
voltage still in bounds.
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/regulator/twl-regulator.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 8f0bd56..03d0bea 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -760,32 +760,28 @@ twl6030smps_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV,
unsigned int *selector)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int vsel = 0;
+ int vsel = 0, calc_uV;
switch (info-flags) {
case 0:
if (min_uV == 0)
vsel = 0;
else if ((min_uV = 60) (min_uV = 130)) {
- int calc_uV;
vsel = DIV_ROUND_UP(min_uV - 60, 12500);
vsel++;
- calc_uV = twl6030smps_list_voltage(rdev, vsel);
- if (calc_uV max_uV)
- return -EINVAL;
}
/* Values 1..57 for vsel are linear and can be calculated
* values 58..62 are non linear.
*/
- else if ((min_uV 190) (max_uV = 210))
+ else if ((min_uV 190) (min_uV = 210))
vsel = 62;
- else if ((min_uV 180) (max_uV = 190))
+ else if ((min_uV 180) (min_uV = 190))
vsel = 61;
- else if ((min_uV 150) (max_uV = 180))
+ else if ((min_uV 150) (min_uV = 180))
vsel = 60;
- else if ((min_uV 135) (max_uV = 150))
+ else if ((min_uV 135) (min_uV = 150))
vsel = 59;
- else if ((min_uV 130) (max_uV = 135))
+ else if ((min_uV 130) (min_uV = 135))
vsel = 58;
else
return -EINVAL;
@@ -794,25 +790,21 @@ twl6030smps_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV,
if (min_uV == 0)
vsel = 0;
else if ((min_uV = 70) (min_uV = 142)) {
- int calc_uV;
vsel = DIV_ROUND_UP(min_uV - 70, 12500);
vsel++;
- calc_uV = twl6030smps_list_voltage(rdev, vsel);
- if (calc_uV max_uV)
- return -EINVAL;
}
/* Values 1..57 for vsel are linear and can be calculated
* values 58..62 are non linear.
*/
- else if ((min_uV 190) (max_uV = 210))
+ else if ((min_uV 190) (min_uV = 210))
vsel = 62;
- else if ((min_uV 180) (max_uV = 190))
+ else if ((min_uV 180) (min_uV = 190))
vsel = 61;
- else if ((min_uV 135) (max_uV = 180))
+ else if ((min_uV 135) (min_uV = 180))
vsel = 60;
- else if ((min_uV 135) (max_uV = 150))
+ else if ((min_uV 135) (min_uV = 150))
vsel = 59;
- else if ((min_uV 130) (max_uV = 135))
+ else if ((min_uV 130) (min_uV = 135))
vsel = 58;
else
return -EINVAL;
@@ -828,13 +820,17 @@ twl6030smps_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV,
case SMPS_OFFSET_EN|SMPS_EXTENDED_EN:
if (min_uV == 0) {
vsel = 0;
- } else if ((min_uV = 2161000) (max_uV = 4321000)) {
+ } else if ((min_uV = 2161000) (min_uV = 4321000)) {
vsel = DIV_ROUND_UP(min_uV - 2161000, 38600);
vsel++;
}
break;
}
+ calc_uV = twl6030smps_list_voltage(rdev, vsel);
+ if (calc_uV max_uV)
+ return -EINVAL;
[PATCH RFT 2/2] regulator: twl: Convert twlsmps_ops to get_voltage_sel and map_voltage
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/regulator/twl-regulator.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 03d0bea..8dae1e3 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -755,12 +755,11 @@ static int twl6030smps_list_voltage(struct regulator_dev
*rdev, unsigned index)
return voltage;
}
-static int
-twl6030smps_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV,
- unsigned int *selector)
+static int twl6030smps_map_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV)
{
- struct twlreg_info *info = rdev_get_drvdata(rdev);
- int vsel = 0, calc_uV;
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int vsel = 0;
switch (info-flags) {
case 0:
@@ -827,14 +826,16 @@ twl6030smps_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV,
break;
}
- calc_uV = twl6030smps_list_voltage(rdev, vsel);
- if (calc_uV max_uV)
- return -EINVAL;
+ return vsel;
+}
- *selector = vsel;
+static int twl6030smps_set_voltage_sel(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE_SMPS,
- vsel);
+ selector);
}
static int twl6030smps_get_voltage_sel(struct regulator_dev *rdev)
@@ -846,8 +847,9 @@ static int twl6030smps_get_voltage_sel(struct regulator_dev
*rdev)
static struct regulator_ops twlsmps_ops = {
.list_voltage = twl6030smps_list_voltage,
+ .map_voltage= twl6030smps_map_voltage,
- .set_voltage= twl6030smps_set_voltage,
+ .set_voltage_sel= twl6030smps_set_voltage_sel,
.get_voltage_sel= twl6030smps_get_voltage_sel,
.enable = twl6030reg_enable,
--
1.7.9.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: [RFC 2/2] net: Add support for NTB virtual ethernet device
On Sat, Jul 14, 2012 at 01:14:03AM +0200, Jiri Pirko wrote:
Fri, Jul 13, 2012 at 11:45:00PM CEST, jon.ma...@intel.com wrote:
A virtual ethernet device that uses the NTB transport API to send/receive
data.
Signed-off-by: Jon Mason jon.ma...@intel.com
---
drivers/net/Kconfig |4 +
drivers/net/Makefile |1 +
drivers/net/ntb_netdev.c | 411
++
3 files changed, 416 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/ntb_netdev.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0c2bd80..9bf8a71 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -178,6 +178,10 @@ config NETPOLL_TRAP
config NET_POLL_CONTROLLER
def_bool NETPOLL
+config NTB_NETDEV
+tristate Virtual Ethernet over NTB
+depends on NTB
+
config RIONET
tristate RapidIO Ethernet over messaging driver support
depends on RAPIDIO
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3d375ca..9890148 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_USB_IPHETH)+= usb/
obj-$(CONFIG_USB_CDC_PHONET) += usb/
obj-$(CONFIG_HYPERV_NET) += hyperv/
+obj-$(CONFIG_NTB_NETDEV) += ntb_netdev.o
diff --git a/drivers/net/ntb_netdev.c b/drivers/net/ntb_netdev.c
new file mode 100644
index 000..bcbd9d4
--- /dev/null
+++ b/drivers/net/ntb_netdev.c
@@ -0,0 +1,411 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2012 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301
USA.
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2012 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copy
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Intel PCIe NTB Network Linux driver
+ *
+ * Contact Information:
+ * Jon Mason jon.ma...@intel.com
+ */
+#include linux/etherdevice.h
+#include linux/ethtool.h
+#include linux/module.h
+#include linux/ntb.h
+
+#define NTB_NETDEV_VER 0.4
Is it really necessary to provide this in-file versioning? Doesn't
kernel version itself do the trick?
Not necessarily. This may be distributed as a package outside of the kernel
and the version is useful for debug.
+
+MODULE_DESCRIPTION(KBUILD_MODNAME);
+MODULE_VERSION(NTB_NETDEV_VER);
+MODULE_LICENSE(Dual BSD/GPL);
+MODULE_AUTHOR(Intel Corporation);
+
+struct ntb_netdev {
+struct net_device *ndev;
+struct ntb_transport_qp *qp;
+};
+
+#define NTB_TX_TIMEOUT_MS
Re: [RFC 2/2] net: Add support for NTB virtual ethernet device
On Fri, Jul 13, 2012 at 05:08:26PM -0700, Stephen Hemminger wrote:
On Fri, 13 Jul 2012 14:45:00 -0700
Jon Mason jon.ma...@intel.com wrote:
A virtual ethernet device that uses the NTB transport API to send/receive
data.
Signed-off-by: Jon Mason jon.ma...@intel.com
---
drivers/net/Kconfig |4 +
drivers/net/Makefile |1 +
drivers/net/ntb_netdev.c | 411
++
3 files changed, 416 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/ntb_netdev.c
+static void ntb_get_drvinfo(__attribute__((unused)) struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ strlcpy(info-driver, KBUILD_MODNAME, sizeof(info-driver));
+ strlcpy(info-version, NTB_NETDEV_VER, sizeof(info-version));
+}
+
+static const char ntb_nic_stats[][ETH_GSTRING_LEN] = {
+ rx_packets, rx_bytes, rx_errors, rx_dropped, rx_length_errors,
+ rx_frame_errors, rx_fifo_errors,
+ tx_packets, tx_bytes, tx_errors, tx_dropped,
+};
+
+static int ntb_get_stats_count(__attribute__((unused)) struct net_device
*dev)
+{
+ return ARRAY_SIZE(ntb_nic_stats);
+}
+
+static int ntb_get_sset_count(struct net_device *dev, int sset)
+{
+ switch (sset) {
+ case ETH_SS_STATS:
+ return ntb_get_stats_count(dev);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static void ntb_get_strings(__attribute__((unused)) struct net_device *dev,
+ u32 sset, u8 *data)
+{
+ switch (sset) {
+ case ETH_SS_STATS:
+ memcpy(data, *ntb_nic_stats, sizeof(ntb_nic_stats));
+ }
+}
+
+static void
+ntb_get_ethtool_stats(struct net_device *dev,
+ __attribute__((unused)) struct ethtool_stats *stats,
+ u64 *data)
+{
+ int i = 0;
+
+ data[i++] = dev-stats.rx_packets;
+ data[i++] = dev-stats.rx_bytes;
+ data[i++] = dev-stats.rx_errors;
+ data[i++] = dev-stats.rx_dropped;
+ data[i++] = dev-stats.rx_length_errors;
+ data[i++] = dev-stats.rx_frame_errors;
+ data[i++] = dev-stats.rx_fifo_errors;
+ data[i++] = dev-stats.tx_packets;
+ data[i++] = dev-stats.tx_bytes;
+ data[i++] = dev-stats.tx_errors;
+ data[i++] = dev-stats.tx_dropped;
+}
These statistics add no value over existing network stats.
Don't implement ethtool stats unless device has something more
interesting to say.
Fair enough
+static const struct ethtool_ops ntb_ethtool_ops = {
+ .get_drvinfo = ntb_get_drvinfo,
+ .get_sset_count = ntb_get_sset_count,
+ .get_strings = ntb_get_strings,
+ .get_ethtool_stats = ntb_get_ethtool_stats,
+ .get_link = ethtool_op_get_link,
+};
If you want to implement bonding or bridging then implementing
get_settings would help.
Will do.
+static int __init ntb_netdev_init_module(void)
+{
+ struct ntb_netdev *dev;
+ int rc;
+
+ pr_info(%s: Probe\n, KBUILD_MODNAME);
Useless message
True, will remove.
Thanks for the comments!
+ netdev = alloc_etherdev(sizeof(struct ntb_netdev));
+ if (!netdev)
+ return -ENOMEM;
+
+ dev = netdev_priv(netdev);
+ dev-ndev = netdev;
+ netdev-features = NETIF_F_HIGHDMA;
+
+ netdev-hw_features = netdev-features;
+ netdev-watchdog_timeo = msecs_to_jiffies(NTB_TX_TIMEOUT_MS);
+
+ random_ether_addr(netdev-perm_addr);
+ memcpy(netdev-dev_addr, netdev-perm_addr, netdev-addr_len);
+
+ netdev-netdev_ops = ntb_netdev_ops;
+ SET_ETHTOOL_OPS(netdev, ntb_ethtool_ops);
+
+ dev-qp = ntb_transport_create_queue(ntb_netdev_rx_handler,
+ntb_netdev_tx_handler,
+ntb_netdev_event_handler);
+ if (!dev-qp) {
+ rc = -EIO;
+ goto err;
+ }
+
+ netdev-mtu = ntb_transport_max_size(dev-qp) - ETH_HLEN;
+
+ rc = register_netdev(netdev);
+ if (rc)
+ goto err1;
+
+ pr_info(%s: %s created\n, KBUILD_MODNAME, netdev-name);
+ return 0;
+
+err1:
+ ntb_transport_free_queue(dev-qp);
+err:
+ free_netdev(netdev);
+ return rc;
+}
+module_init(ntb_netdev_init_module);
+
+static void __exit ntb_netdev_exit_module(void)
+{
+ struct ntb_netdev *dev = netdev_priv(netdev);
+
+ unregister_netdev(netdev);
+ ntb_transport_free_queue(dev-qp);
+ free_netdev(netdev);
+
+ pr_info(%s: Driver removed\n, KBUILD_MODNAME);
+}
+module_exit(ntb_netdev_exit_module);
--
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/8] time: Condense timekeeper.xtime into xtime_sec
* John Stultz wrote:
> +static void tk_set_xtime(struct timekeeper *tk, const struct timespec *ts)
> +{
> + tk->xtime_sec = ts->tv_sec;
> + tk->xtime_nsec = ts->tv_nsec << tk->shift;
> +}
> +
> +
> +static void tk_xtime_add(struct timekeeper *tk, const struct timespec *ts)
Small nit: there's a stray newline here.
> +{
> + tk->xtime_sec += ts->tv_sec;
> + tk->xtime_nsec += ts->tv_nsec << tk->shift;
> +}
> +
>
> /**
Ditto.
Thanks,
Ingo
--
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 for v3.5-rc7] media fixes
Hi Linus, Plese pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for the fixes for the media subsystem, including: - Some regression fixes at the audio part for devices with cx23885/cx25840; - A DMA corruption fix at cx231xx; - two fixes at the winbond IR driver; - Several fixes for the EXYNOS media driver (s5p); - two fixes at the OMAP3 preview driver; - one fix at the dvb core failure path; - an include missing (slab.h) at smiapp-core causing compilation breakage; - em28xx was not loading the IR driver driver anymore. PS.: I'll be out next week due to holidays. Thanks! Mauro Latest commit at the branch: ec3ed85f926f4e900bc48cec6e72abbe6475321f [media] Revert "[media] V4L: JPEG class documentation corrections" The following changes since commit 099987f0aaf28771261b91a41240b9228f2e32b2: [media] smia: Fix compile failures (2012-06-18 19:52:05 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to ec3ed85f926f4e900bc48cec6e72abbe6475321f: [media] Revert "[media] V4L: JPEG class documentation corrections" (2012-07-07 00:12:50 -0300) Anton Blanchard (3): [media] cx23885: Silence unknown command warnings [media] winbond-cir: Fix txandrx module info [media] winbond-cir: Initialise timeout, driver_type and allowed_protos David Dillow (1): [media] cx231xx: don't DMA to random addresses Devin Heitmueller (6): [media] cx25840: fix regression in HVR-1800 analog support [media] cx25840: fix regression in analog support hue/saturation controls [media] cx25840: fix regression in HVR-1800 analog audio [media] cx25840: fix vsrc/hsrc usage on cx23888 designs [media] cx23885: make analog support work for HVR_1250 (cx23885 variant) [media] cx23885: add support for HVR-1255 analog (cx23888 variant) Fengguang Wu (1): [media] pms: fix build error in pms_probe() Kamil Debski (1): [media] s5p-mfc: Fixed setup of custom controls in decoder and encoder Laurent Pinchart (2): [media] omap3isp: preview: Fix output size computation depending on input format [media] omap3isp: preview: Fix contrast and brightness handling Mauro Carvalho Chehab (2): [media] smiapp-core: fix compilation build error [media] em28xx: fix em28xx-rc load Randy Dunlap (1): [media] media: pms.c needs linux/slab.h Sachin Kamat (2): [media] s5p-fimc: Fix compiler warning in fimc-lite.c [media] s5p-fimc: Stop media entity pipeline if fimc_pipeline_validate fails Sakari Ailus (1): [media] s5p-fimc: media_entity_pipeline_start() may fail Santosh Nayak (1): [media] dvb-core: Release semaphore on error path dvb_register_device() Sylwester Nawrocki (10): [media] s5p-fimc: Fix bug in capture node open() [media] s5p-fimc: Don't create multiple active links to same sink entity [media] s5p-fimc: Honour sizeimage in VIDIOC_S_FMT [media] s5p-fimc: Remove superfluous checks for buffer type [media] s5p-fimc: Prevent lock-up in multiple sensor systems [media] s5p-fimc: Fix fimc-lite system wide suspend procedure [media] s5p-fimc: Shorten pixel formats description [media] s5p-fimc: Update to the control handler lock changes [media] s5p-fimc: Add missing FIMC-LITE file operations locking [media] Revert "[media] V4L: JPEG class documentation corrections" Documentation/DocBook/media/v4l/controls.xml |2 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 -- drivers/media/dvb/dvb-core/dvbdev.c|1 + drivers/media/rc/winbond-cir.c |4 +- drivers/media/video/cx231xx/cx231xx-audio.c|4 +- drivers/media/video/cx231xx/cx231xx-vbi.c |2 +- drivers/media/video/cx23885/cx23885-cards.c| 89 +--- drivers/media/video/cx23885/cx23885-dvb.c |6 ++ drivers/media/video/cx23885/cx23885-video.c|9 +- drivers/media/video/cx23885/cx23885.h |1 + drivers/media/video/cx25840/cx25840-core.c | 76 - drivers/media/video/em28xx/em28xx-cards.c |2 +- drivers/media/video/omap3isp/isppreview.c |6 +- drivers/media/video/pms.c |2 + drivers/media/video/s5p-fimc/fimc-capture.c| 69 --- drivers/media/video/s5p-fimc/fimc-core.c | 19 +++-- drivers/media/video/s5p-fimc/fimc-lite.c | 73 +++- drivers/media/video/s5p-fimc/fimc-mdevice.c| 48 +-- drivers/media/video/s5p-fimc/fimc-mdevice.h|2 - drivers/media/video/s5p-mfc/s5p_mfc_dec.c |1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c
Re: [PATCH 7/8] time: Move xtime_nsec adjustment underflow handling timekeeping_adjust
* John Stultz wrote: > When we make adjustments speeding up the clock, its possible > for xtime_nsec to underflow. We already handle this properly, > but we do so from update_wall_time() instead of the more logical > timekeeping_adjust(), where the possible underflow actually > occurs. > > Thus, move the correction logic to the timekeeping_adjust, which > is the function that causes the issue. Making update_wall_time() > more readable. > > CC: Ingo Molnar > CC: Peter Zijlstra > CC: Richard Cochran > CC: Prarit Bhargava > CC: Thomas Gleixner > Signed-off-by: John Stultz > --- > kernel/time/timekeeping.c | 42 +- > 1 file changed, 21 insertions(+), 21 deletions(-) > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index dd119355..4b76432 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -987,6 +987,27 @@ static void timekeeping_adjust(s64 offset) > timekeeper.xtime_nsec -= offset; > timekeeper.ntp_error -= (interval - offset) << > timekeeper.ntp_error_shift; > + > + /* > + * It may be possible that when we entered this function, xtime_nsec > + * was very small. Further, if we're slightly speeding the clocksource > + * in the code above, its possible the required corrective factor to > + * xtime_nsec could cause it to underflow. s/slightly speeding/slightly speeding up ? > + * > + * Now, since we already accumulated the second, cannot simply roll > + * the accumulated second back, since the NTP subsystem has been s/cannot/we cannot ? Thanks, Ingo -- 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: How to use the generic thermal sysfs.
On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote: As of now, we are getting the definitions done through the platform layer data. Considerations for device tree .. yes.. but I do not have any sample implementation.. Maybe we can help with that then, since we are going to need it. On the public tree: Rui is trying to get a public tree from where we can pull Thermal subsystem changes; and submit patches against this tree. I hope Rui will publish the link very soon :-) Excellent. Could you keep us posted when this happens? Thanks! Alex. -- 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 5/8] time: Refactor accumulation of nsecs to secs
* John Stultz wrote: > +} > + > + > +/** Stray newline added here as well. Thanks, Ingo -- 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: How to use the generic thermal sysfs.
On 五, 2012-07-13 at 15:08 +0900, Alex Courbot wrote: > On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote: > > As of now, we are getting the definitions done through the platform layer > > data. Considerations for device tree .. yes.. but I do not have any sample > > implementation.. > > Maybe we can help with that then, since we are going to need it. > > > On the public tree: > > Rui is trying to get a public tree from where we can pull Thermal subsystem > > changes; and submit patches against this tree. > > > > I hope Rui will publish the link very soon :-) > > Excellent. Could you keep us posted when this happens? > sure. I'm just working on a patch set and I hope to push them to git.kernel.org by next week. thanks, rui -- 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 6/8] time: Move arch_gettimeoffset() usage into timekeeping_get_ns()
* John Stultz wrote: > + nsec >>= timekeeper.shift; > + > + /* If arch requires, add in gettimeoffset() */ > + nsec += arch_gettimeoffset(); > + return nsec; As a factoring out bonus, this could be further shortened to: return nsec + arch_gettimeoffset(); > + /* If arch requires, add in gettimeoffset() */ > + nsec += arch_gettimeoffset(); > + return nsec; Ditto. Thanks, Ingo -- 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 0/8] Time fixes and cleanups for 3.6
Looks sensible. Reviewed-by: Ingo Molnar Thanks, Ingo -- 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/
MAINTAINERS: bounces, remove or update?
The @smsc.com email address is bouncing. Should it be removed from MAINTAINERS or switched to this @shawell.net address? -- 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 RFC V3 2/3] kvm: Note down when cpu relax intercepted or pause loop exited
On 13/07/12 05:35, Raghavendra K T wrote: > Yes! I forgot about archs in init function. > How about having > #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT > vcpu->ple.cpu_relax_intercepted = false; > vcpu->ple.dy_eligible = false; > #endif > > This would solve all the problem. No, you need to mask all places > >>> >>> r = kvm_arch_vcpu_init(vcpu); >>> if (r< 0) >>> @@ -1577,6 +1579,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me) >>> int pass; >>> int i; >>> >>> +me->ple.cpu_relax_intercepted = true; >> >> dito > > currently vcpu_on_spin is used only by x86 and s390. so if some other > arch in future uses vcpu_on_spin, I believe they also have to enable > CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT > what do you think? ...because this function is compiled no matter if called or not. > >> maybe define static inline access functions in kvm_host.h that are no-ops >> if CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT is not set. As I already said, can you have a look at using access functions? -- 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 2/3 RESEND] acpi : prevent cpu from becoming online
2012/07/12 21:41, Srivatsa S. Bhat wrote:
> On 07/12/2012 05:10 PM, Yasuaki Ishimatsu wrote:
>> Even if acpi_processor_handle_eject() offlines cpu, there is a chance
>> to online the cpu after that. So the patch closes the window by using
>> get/put_online_cpus().
>>
>> Why does the patch change _cpu_up() logic?
>>
>> The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
>> does not change it, there is the following race.
>>
>> hot-remove cpu | _cpu_up()
>> -
>> call acpi_processor_handle_eject() |
>> call cpu_down() |
>> call get_online_cpus()|
>> | call cpu_hotplug_begin() and stop
>> here
>> call arch_unregister_cpu()|
>> call acpi_unmap_lsapic() |
>> call put_online_cpus()|
>> | start and continue _cpu_up()
>> return acpi_processor_remove()|
>> continue hot-remove the cpu|
>>
>> So _cpu_up() can continue to itself. And hot-remove cpu can also continue
>> itself. If the patch changes _cpu_up() logic, the race disappears as below:
>>
>> hot-remove cpu | _cpu_up()
>> ---
>> call acpi_processor_handle_eject() |
>> call cpu_down() |
>> call get_online_cpus()|
>> | call cpu_hotplug_begin() and stop
>> here
>> call arch_unregister_cpu()|
>> call acpi_unmap_lsapic() |
>>cpu's cpu_present is set |
>>to false by set_cpu_present()|
>> call put_online_cpus()|
>> | start _cpu_up()
>> | check cpu_present() and return
>> -EINVAL
>> return acpi_processor_remove()|
>> continue hot-remove the cpu|
>>
>> Signed-off-by: Yasuaki Ishimatsu
>>
>
> Please consider fixing the grammar issue below (since it is a user-visible
> print statement). Other than that, everything looks fine.
>
> Reviewed-by: Srivatsa S. Bhat
>
>> ---
>> drivers/acpi/processor_driver.c | 14 ++
>> kernel/cpu.c|8 +---
>> 2 files changed, 19 insertions(+), 3 deletions(-)
>>
>> Index: linux-3.5-rc6/drivers/acpi/processor_driver.c
>> ===
>> --- linux-3.5-rc6.orig/drivers/acpi/processor_driver.c 2012-07-12
>> 20:34:29.438289841 +0900
>> +++ linux-3.5-rc6/drivers/acpi/processor_driver.c2012-07-12
>> 20:39:29.190542257 +0900
>> @@ -850,8 +850,22 @@ static int acpi_processor_handle_eject(s
>> return ret;
>> }
>>
>> +get_online_cpus();
>> +/*
>> + * The cpu might become online again at this point. So we check whether
>> + * the cpu has been onlined or not. If the cpu became online, it means
>> + * that someone wants to use the cpu. So acpi_processor_handle_eject()
>> + * returns -EAGAIN.
>> + */
>> +if (unlikely(cpu_online(pr->id))) {
>> +put_online_cpus();
>> +printk(KERN_WARNING "Failed to remove CPU %d, "
>> + "since someone onlines the cpu\n" , pr->id);
>
> How about:
> "Failed to remove CPU %d, because some other task brought the CPU back
> online\n"
Looks good to me. I'll update it.
Thanks,
Yasuaki Ishimatsu
>
> Regards,
> Srivatsa S. Bhat
>
>> +return -EAGAIN;
>> +}
>> arch_unregister_cpu(pr->id);
>> acpi_unmap_lsapic(pr->id);
>> +put_online_cpus();
>> return ret;
>> }
>> #else
>> Index: linux-3.5-rc6/kernel/cpu.c
>> ===
>> --- linux-3.5-rc6.orig/kernel/cpu.c 2012-07-12 20:34:29.438289841 +0900
>> +++ linux-3.5-rc6/kernel/cpu.c 2012-07-12 20:34:35.040219535 +0900
>> @@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
>> unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
>> struct task_struct *idle;
>>
>> -if (cpu_online(cpu) || !cpu_present(cpu))
>> -return -EINVAL;
>> -
>> cpu_hotplug_begin();
>>
>> +if (cpu_online(cpu) || !cpu_present(cpu)) {
>> +ret = -EINVAL;
>> +goto out;
>> +}
>> +
>> idle = idle_thread_get(cpu);
>> if (IS_ERR(idle)) {
>> ret = PTR_ERR(idle);
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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
Re: [PATCH v3 1/3] acpi : cpu hot-remove returns error when cpu_down() fails
Hi Toshi,
2012/07/13 1:48, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:22 +0900, Yasuaki Ishimatsu wrote:
Even if cpu_down() fails, acpi_processor_remove() continues to remove the cpu.
But in this case, it should return error number since some process may run on
the cpu. If the cpu has a running process and the cpu is turned the power off,
the system may not work well.
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/processor_driver.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-06-25
04:53:04.0 +0900
+++ linux-3.5-rc4/drivers/acpi/processor_driver.c 2012-07-05
21:02:58.711285382 +0900
@@ -610,7 +610,7 @@ err_free_pr:
static int acpi_processor_remove(struct acpi_device *device, int type)
{
struct acpi_processor *pr = NULL;
-
+ int ret;
if (!device || !acpi_driver_data(device))
return -EINVAL;
@@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
goto free;
if (type == ACPI_BUS_REMOVAL_EJECT) {
- if (acpi_processor_handle_eject(pr))
- return -EINVAL;
+ ret = acpi_processor_handle_eject(pr);
+ if (ret)
+ return ret;
}
acpi_processor_power_exit(pr, device);
@@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
static int acpi_processor_handle_eject(struct acpi_processor *pr)
{
- if (cpu_online(pr->id))
- cpu_down(pr->id);
+ int ret;
+
+ if (cpu_online(pr->id)) {
+ ret = cpu_down(pr->id);
+ if (ret)
+ return ret;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
- return (0);
+ return ret;
ret is uninitialized when !cpu_online().
Oops! I'll update it.
Thanks,
Yasuaki Ishimatsu
Thanks,
-Toshi
}
#else
static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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-acpi" 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: [PATCH v3 2/3 RESEND] acpi : prevent cpu from becoming online
Hi Toshi,
2012/07/13 1:49, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:40 +0900, Yasuaki Ishimatsu wrote:
Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().
Why does the patch change _cpu_up() logic?
The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it, there is the following race.
hot-remove cpu | _cpu_up()
-
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus()|
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu()|
call acpi_unmap_lsapic() |
call put_online_cpus()|
| start and continue _cpu_up()
return acpi_processor_remove()|
continue hot-remove the cpu|
So _cpu_up() can continue to itself. And hot-remove cpu can also continue
itself. If the patch changes _cpu_up() logic, the race disappears as below:
hot-remove cpu | _cpu_up()
---
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus()|
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu()|
call acpi_unmap_lsapic() |
cpu's cpu_present is set |
to false by set_cpu_present()|
call put_online_cpus()|
| start _cpu_up()
| check cpu_present() and return -EINVAL
return acpi_processor_remove()|
continue hot-remove the cpu|
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/processor_driver.c | 14 ++
kernel/cpu.c|8 +---
2 files changed, 19 insertions(+), 3 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc6.orig/drivers/acpi/processor_driver.c 2012-07-12
20:34:29.438289841 +0900
+++ linux-3.5-rc6/drivers/acpi/processor_driver.c 2012-07-12
20:39:29.190542257 +0900
@@ -850,8 +850,22 @@ static int acpi_processor_handle_eject(s
return ret;
}
+ get_online_cpus();
+ /*
+* The cpu might become online again at this point. So we check whether
+* the cpu has been onlined or not. If the cpu became online, it means
+* that someone wants to use the cpu. So acpi_processor_handle_eject()
+* returns -EAGAIN.
+*/
+ if (unlikely(cpu_online(pr->id))) {
+ put_online_cpus();
+ printk(KERN_WARNING "Failed to remove CPU %d, "
+ "since someone onlines the cpu\n" , pr->id);
pr_warn() should be used per the recent checkpatch change.
O.K. I'll update it.
Thanks,
Yasuaki Ishimatsu
Thanks,
-Toshi
+ return -EAGAIN;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
+ put_online_cpus();
return ret;
}
#else
Index: linux-3.5-rc6/kernel/cpu.c
===
--- linux-3.5-rc6.orig/kernel/cpu.c 2012-07-12 20:34:29.438289841 +0900
+++ linux-3.5-rc6/kernel/cpu.c 2012-07-12 20:34:35.040219535 +0900
@@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
struct task_struct *idle;
- if (cpu_online(cpu) || !cpu_present(cpu))
- return -EINVAL;
-
cpu_hotplug_begin();
+ if (cpu_online(cpu) || !cpu_present(cpu)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
idle = idle_thread_get(cpu);
if (IS_ERR(idle)) {
ret = PTR_ERR(idle);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [PATCH 2/2] dma: tegra: fix residual calculation for cyclic case
On Fri, 2012-07-13 at 11:09 +0530, Laxman Dewangan wrote: > On Friday 13 July 2012 08:45 AM, Vinod Koul wrote: > > On Mon, 2012-07-02 at 10:02 -0600, Stephen Warren wrote: > >> On 07/02/2012 02:22 AM, Laxman Dewangan wrote: > >>> In cyclic mode of DMA, the byte transferred can be more > >>> than the requested size and in this case, calculating > >>> residuals based on the current position of DMA transfer to > >>> bytes requested i.e. bytes required to transfer to reach > >>> bytes requested from current DMA position. > >>> > >>> Signed-off-by: Laxman Dewangan > >> This makes sense to me, although I wonder if details like this aren't > >> something that the dmaengine core should be handling. > > No core doesn't know anything about the how much you are transferring > > and where you are. That is the driver to calculate and provide. > > Just for confirmation, are you going to apply this patch or do I need to > do anything here. ??? You didnt get my other mail about applying? -- ~Vinod -- 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 1/3] acpi : cpu hot-remove returns error when cpu_down() fails
Hi Srivatsa,
2012/07/12 21:32, Srivatsa S. Bhat wrote:
> On 07/12/2012 04:52 PM, Yasuaki Ishimatsu wrote:
>> Even if cpu_down() fails, acpi_processor_remove() continues to remove the
>> cpu.
>> But in this case, it should return error number since some process may run on
>> the cpu. If the cpu has a running process and the cpu is turned the power
>> off,
>> the system may not work well.
>>
>> Signed-off-by: Yasuaki Ishimatsu
>>
>
> Reviewed-by: Srivatsa S. Bhat
Thank you for reviewing.
Thanks,
Yasuaki Ishimatsu
> Regards,
> Srivatsa S. Bhat
>
>> ---
>> drivers/acpi/processor_driver.c | 18 --
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
>> ===
>> --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-06-25
>> 04:53:04.0 +0900
>> +++ linux-3.5-rc4/drivers/acpi/processor_driver.c2012-07-05
>> 21:02:58.711285382 +0900
>> @@ -610,7 +610,7 @@ err_free_pr:
>> static int acpi_processor_remove(struct acpi_device *device, int type)
>> {
>> struct acpi_processor *pr = NULL;
>> -
>> +int ret;
>>
>> if (!device || !acpi_driver_data(device))
>> return -EINVAL;
>> @@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
>> goto free;
>>
>> if (type == ACPI_BUS_REMOVAL_EJECT) {
>> -if (acpi_processor_handle_eject(pr))
>> -return -EINVAL;
>> +ret = acpi_processor_handle_eject(pr);
>> +if (ret)
>> +return ret;
>> }
>>
>> acpi_processor_power_exit(pr, device);
>> @@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
>>
>> static int acpi_processor_handle_eject(struct acpi_processor *pr)
>> {
>> -if (cpu_online(pr->id))
>> -cpu_down(pr->id);
>> +int ret;
>> +
>> +if (cpu_online(pr->id)) {
>> +ret = cpu_down(pr->id);
>> +if (ret)
>> +return ret;
>> +}
>>
>> arch_unregister_cpu(pr->id);
>> acpi_unmap_lsapic(pr->id);
>> -return (0);
>> +return ret;
>> }
>> #else
>> static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [PATCH 1/8 v2] i2c: i2c-bfin-twi: Illegal i2c bus lock upon certain transfer scenarios.
On Wed, Jun 13, 2012 at 04:22:40PM +0800, Sonic Zhang wrote:
> From: Michael Hennerich
>
> For transfer counts > 255 bytes i2c-bfin-twi sets the data
> transfer counter DCNT to 0xFF indicating unlimited transfers.
> It then uses a flag iface->manual_stop to manually issue the STOP
> condition, once the required amount of bytes are received.
>
> We found that on I2C receive operation issuing the STOP condition
> together with a FULL RCV FIFO (2bytes) will cause SDA and SCL be
> constantly driven low.
>
> Temporary workaround until further investigation:
> Discard the RCV FIFO before issuing the STOP condition.
>
> Signed-off-by: Michael Hennerich
> Signed-off-by: Sonic Zhang
All 8 patches applied to next, thanks.
If you want to make my life easier, please state what changed from V1 to
V2. I had to look it up manually which costs time and doesn't make the
patchset look like a low-hanging fruit.
> ---
> drivers/i2c/busses/i2c-bfin-twi.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
> b/drivers/i2c/busses/i2c-bfin-twi.c
> index cdb59e5..33031f0 100644
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> @@ -131,6 +131,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> iface->transPtr++;
> iface->readNum--;
> } else if (iface->manual_stop) {
> + /* Temporary workaround to avoid possible bus stall -
> + * Flush FIFO before issuing the STOP condition
> + */
> + read_RCV_DATA16(iface);
> write_MASTER_CTL(iface,
> read_MASTER_CTL(iface) | STOP);
> } else if (iface->cur_mode == TWI_I2C_MODE_REPEAT &&
> --
> 1.7.0.4
>
>
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Thu, 2012-07-12 at 15:31 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jul 2012, Mike Galbraith wrote:
> > On Thu, 2012-07-12 at 13:43 +0200, Thomas Gleixner wrote:
> > > rawlock points to ...968 and the node_list to ...970.
> > >
> > > struct rt_mutex {
> > > raw_spinlock_t wait_lock;
> > > struct plist_head wait_list;
> > >
> > > The raw_lock pointer of the plist_head is initialized in
> > > __rt_mutex_init() so it points to wait_lock.
> > >
> > > Can you check the offset of wait_list vs. the rt_mutex itself?
> > >
> > > I wouldn't be surprised if it's exactly 8 bytes. And then this thing
> > > looks like a copied lock with stale pointers to hell. Eew.
> >
> > crash> struct rt_mutex -o
> > struct rt_mutex {
> >[0] raw_spinlock_t wait_lock;
> >[8] struct plist_head wait_list;
>
> Bingo, that makes it more likely that this is caused by copying w/o
> initializing the lock and then freeing the original structure.
>
> A quick check for memcpy finds that __btrfs_close_devices() does a
> memcpy of btrfs_device structs w/o initializing the lock in the new
> copy, but I have no idea whether that's the place we are looking for.
Thanks a bunch Thomas. I doubt I would have ever figured out that lala
land resulted from _copying_ a lock. That's one I won't be forgetting
any time soon. Box not only survived a few thousand xfstests 006 runs,
dbench seemed disinterested in deadlocking virgin 3.0-rt.
btrfs still locks up in my enterprise kernel, so I suppose I had better
plug your fix into 3.4-rt and see what happens, and go beat hell out of
virgin 3.0-rt again to be sure box really really survives dbench.
> tglx
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 43baaf0..06c8ced 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -512,6 +512,7 @@ static int __btrfs_close_devices(struct btrfs_fs_devices
> *fs_devices)
> new_device->writeable = 0;
> new_device->in_fs_metadata = 0;
> new_device->can_discard = 0;
> + spin_lock_init(_device->io_lock);
> list_replace_rcu(>dev_list, _device->dev_list);
>
> call_rcu(>rcu, free_device);
>
>
>
> --
> 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/
--
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/8 v2] i2c: i2c-bfin-twi: Tighten condition when failing I2C transfer if MEN bit is reset unexpectedly.
On Wed, Jun 13, 2012 at 04:22:43PM +0800, Sonic Zhang wrote:
> From: Sonic Zhang
>
> In order to mark I2C transfer fail when MEN bit in I2C controller is reset
> unexpeced
"unexpected"
> in MCOMP interrupt, interrupt status bits XMTSERV or RCVSERV should be
> checked.
>
> Master Transfer Complete (MCOMP).
> [1] The initiated master transfer has completed. In the absence of a
> repeat start, the bus has been released.
> [0] The completion of a transfer has not been detected.
>
> Signed-off-by: Sonic Zhang
> ---
> drivers/i2c/busses/i2c-bfin-twi.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
> b/drivers/i2c/busses/i2c-bfin-twi.c
> index a5ab454..2e59bbd 100644
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> @@ -201,7 +201,8 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> return;
> }
> if (twi_int_status & MCOMP) {
> - if ((read_MASTER_CTL(iface) & MEN) == 0 &&
> + if (twi_int_status & (XMTSERV|RCVSERV) &&
Spaces around operators.
I fixed both for you.
> + (read_MASTER_CTL(iface) & MEN) == 0 &&
> (iface->cur_mode == TWI_I2C_MODE_REPEAT ||
> iface->cur_mode == TWI_I2C_MODE_COMBINED)) {
> iface->result = -1;
> --
> 1.7.0.4
>
>
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH 5/8 v2] i2c:i2c-bfin-twi: TWI fails to restart next transfer in high system load.
On Wed, Jun 13, 2012 at 04:22:44PM +0800, Sonic Zhang wrote:
> From: Sonic Zhang
>
> Current driver was developed based on BF537 0.2 HRM. In high system load,
> BUFRDERR error
> interrupt may be raised if XMTSERV interrupt of last TX byte is not served in
> time
> (set RSTART bit), which breaks restart tranfer as expected.
>
> "Buffer Read Error (BUFRDERR)" description in Blackfin HRM only applys to
> BF537
> rev. < 0.3. In later rev. and later announced Blackfin chips, such as BF527
> and
> BF548, a new TWI master feature "Clock Stretching" is added into the TWI
> controller,
> BUFRDERR interrupt is not triggered after TX FIFO is empty.
>
> This patch sets RSTART bit at the beginning of the first transfer. The SCL
> and SDA
> is hold till XMTSERV interrupt of last TX byte is served. Restart transfer is
> not broken
> in high system load.
>
> Signed-off-by: Sonic Zhang
> ---
> drivers/i2c/busses/i2c-bfin-twi.c | 23 +--
> 1 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
> b/drivers/i2c/busses/i2c-bfin-twi.c
> index 2e59bbd..e75ee91 100644
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> @@ -99,7 +99,7 @@ static void bfin_twi_handle_interrupt(struct bfin_twi_iface
> *iface,
>*/
> else if (iface->cur_mode == TWI_I2C_MODE_COMBINED)
> write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) | MDIR | RSTART);
> + read_MASTER_CTL(iface) | MDIR);
> else if (iface->manual_stop)
> write_MASTER_CTL(iface,
> read_MASTER_CTL(iface) | STOP);
> @@ -107,10 +107,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
>iface->cur_msg + 1 < iface->msg_num) {
> if (iface->pmsg[iface->cur_msg + 1].flags & I2C_M_RD)
> write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) | RSTART | MDIR);
> + read_MASTER_CTL(iface) | MDIR);
> else
> write_MASTER_CTL(iface,
> - (read_MASTER_CTL(iface) | RSTART) &
> ~MDIR);
> + read_MASTER_CTL(iface) & ~MDIR);
> }
> }
> if (twi_int_status & RCVSERV) {
> @@ -144,10 +144,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> iface->cur_msg + 1 < iface->msg_num) {
> if (iface->pmsg[iface->cur_msg + 1].flags &
> I2C_M_RD)
> write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) | RSTART
> | MDIR);
> + read_MASTER_CTL(iface) | MDIR);
> else
> write_MASTER_CTL(iface,
> - (read_MASTER_CTL(iface) |
> RSTART) & ~MDIR);
> + read_MASTER_CTL(iface) & ~MDIR);
> }
> }
> }
> @@ -262,9 +262,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> (0xff << 6)));
> iface->manual_stop = 1;
> }
> - /* remove restart bit and enable master receive */
> - write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) & ~RSTART);
> + /* remove restart bit before last message */
> + if (iface->cur_msg+1 == iface->msg_num)
Spaces around operators. I fixed it for you.
> + write_MASTER_CTL(iface,
> + read_MASTER_CTL(iface) & ~RSTART);
> } else {
> iface->result = 1;
> write_INT_MASK(iface, 0);
> @@ -321,7 +322,8 @@ static int bfin_twi_do_master_xfer(struct i2c_adapter
> *adap,
> return -EINVAL;
> }
>
> - iface->cur_mode = TWI_I2C_MODE_REPEAT;
> + if (iface->msg_num > 1)
> + iface->cur_mode = TWI_I2C_MODE_REPEAT;
> iface->manual_stop = 0;
> iface->transPtr = pmsg->buf;
> iface->writeNum = iface->readNum = pmsg->len;
> @@ -366,6 +368,7 @@ static int bfin_twi_do_master_xfer(struct i2c_adapter
> *adap,
>
> /* Master enable */
> write_MASTER_CTL(iface, read_MASTER_CTL(iface) | MEN |
> + (iface->msg_num > 1 ? RSTART : 0) |
> ((iface->read_write == I2C_SMBUS_READ) ? MDIR : 0) |
> ((CONFIG_I2C_BLACKFIN_TWI_CLK_KHZ > 100) ? FAST : 0));
> SSYNC();
> @@ -530,7 +533,7 @@ int
Re: [PATCH 2/2] dma: tegra: fix residual calculation for cyclic case
On Friday 13 July 2012 11:58 AM, Vinod Koul wrote: On Fri, 2012-07-13 at 11:09 +0530, Laxman Dewangan wrote: You didnt get my other mail about applying? Read carefully now and saw both are applied. Thanks for care. Thanks, Laxman -- 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] Input: eeti_ts: Mark as CONFIG_BROKEN
On Wed, May 02, 2012 at 09:36:51PM -0700, Dmitry Torokhov wrote: > Hi Sven, > > On Sat, Apr 07, 2012 at 08:38:33PM +0200, Sven Neumann wrote: > > Hi, > > > > On 07.04.12 09:02, Dmitry Torokhov wrote: > > >On Fri, Apr 06, 2012 at 10:40:07PM -0700, Olof Johansson wrote: > > >>This seems to have been broken since 2010, so obviously noone actually > > >>cares about the driver: > > >> > > >>make[4]: *** [drivers/input/touchscreen/eeti_ts.o] Error 1 > > >>drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active': > > >>drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of > > >>function 'irq_to_gpio' [-Werror=implicit-function-declaration] > > >> > > >>irq_to_gpio isn't available on most platforms today, so the driver > > >>will need some rework by someone who has hardware access and can test > > >>(to make sure that, for example, switching to level interrupts and just > > >>keep taking them while there's more to process works). > > >> > > >>I guess it could just be scheduled for removal, but let's start with > > >>marking it CONFIG_BROKEN. > > > > > >Well, it probably works quite well on arches that do have irq_to_gpio(), > > >let's ask Daniel and Sven if they still have this hardware and if they > > >can try the patch below that implements what you suggested. > > > > This hardware is still in use and we also still follow kernel > > development and try to update our customer devices to recent kernel > > versions regularly. Currently we are at 3.1.10 and the touchscreen > > works well with that. I'll try to update to a more recent kernel > > next week and will try your patch. > > > > Did you have a chance to test the patch? *ping* It would be nice to get driver in mainline compile [and work] again... Thanks. -- Dmitry -- 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: ARM: why smp_mb() is not needed in the "__mutex_fastpath_lock" and "__mutex_fastpath_unlock" functions
Hi Shan, 2012/7/12 shan kang : > Hello, >I wonder why smp_mb() is not needed in the "__mutex_fastpath_lock" > and "__mutex_fastpath_unlock" functions which are located in the > "arch/arm/include/asm/mutex.h"? >I think "dmb" instruction is necessary there. Why necessary? Could you explain more detailed? > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 v2] USB: ehci-s5p: Add support for device tree
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ehci driver for exynos using device tree
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index c474cec..52d0049 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -13,6 +13,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -63,6 +64,8 @@ static const struct hc_driver s5p_ehci_hc_driver = {
> .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
> };
>
> +static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
> +
> static int __devinit s5p_ehci_probe(struct platform_device *pdev)
> {
> struct s5p_ehci_platdata *pdata;
> @@ -79,6 +82,16 @@ static int __devinit s5p_ehci_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> + /*
> + * Right now device-tree probed devices don't get dma_mask set.
> + * Since shared usb code relies on it, set it here for now.
> + * Once we move to full device tree support this will vanish off.
> + */
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = _s5p_dma_mask;
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> s5p_ehci = kzalloc(sizeof(struct s5p_ehci_hcd), GFP_KERNEL);
This makes conflict on 'usb-next' branch.
Please re-base the patch on 'usb-next' branch.
> if (!s5p_ehci)
> return -ENOMEM;
> @@ -298,6 +311,14 @@ static int s5p_ehci_resume(struct device *dev)
> #define s5p_ehci_resume NULL
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_ehci_match[] = {
> + { .compatible = "samsung,exynos-ehci" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_ehci_match);
> +#endif
> +
Please move " struct of_device_id exynos_ehci_match[]"
to the next of "struct dev_pm_ops s5p_ehci_pm_ops",
as you did at 1st patch '[PATCH 1/3 v2] USB: ohci-exynos: Add support for
device tree'.
Please keep the code sync as possible.
> static const struct dev_pm_ops s5p_ehci_pm_ops = {
> .suspend= s5p_ehci_suspend,
> .resume = s5p_ehci_resume,
> @@ -311,6 +332,7 @@ static struct platform_driver s5p_ehci_driver = {
> .name = "s5p-ehci",
> .owner = THIS_MODULE,
> .pm = _ehci_pm_ops,
> + .of_match_table = of_match_ptr(exynos_ehci_match),
> }
> };
>
> --
> 1.7.0.4
--
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 v2] USB: ohci-exynos: Add support for device tree
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ohci driver for exynos using device tree.
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 2909621..c4ad60f 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -12,6 +12,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -71,6 +72,8 @@ static const struct hc_driver exynos_ohci_hc_driver = {
> .start_port_reset = ohci_start_port_reset,
> };
>
> +static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
> +
> static int __devinit exynos_ohci_probe(struct platform_device *pdev)
> {
> struct exynos4_ohci_platdata *pdata;
> @@ -87,6 +90,16 @@ static int __devinit exynos_ohci_probe(struct
> platform_device *pdev)
> return -EINVAL;
> }
>
> + /*
> + * Right now device-tree probed devices don't get dma_mask set.
> + * Since shared usb code relies on it, set it here for now.
> + * Once we move to full device tree support this will vanish off.
> + */
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = _exynos_dma_mask;
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> exynos_ohci = kzalloc(sizeof(struct exynos_ohci_hcd), GFP_KERNEL);
This makes conflict on 'usb-next' branch.
Please re-base the patch on 'usb-next' branch.
> if (!exynos_ohci)
> return -ENOMEM;
> @@ -258,6 +271,14 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
> .resume = exynos_ohci_resume,
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_ohci_match[] = {
> + { .compatible = "samsung,exynos-ohci" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_ohci_match);
> +#endif
> +
> static struct platform_driver exynos_ohci_driver = {
> .probe = exynos_ohci_probe,
> .remove = __devexit_p(exynos_ohci_remove),
> @@ -266,6 +287,7 @@ static struct platform_driver exynos_ohci_driver = {
> .name = "exynos-ohci",
> .owner = THIS_MODULE,
> .pm = _ohci_pm_ops,
> + .of_match_table = of_match_ptr(exynos_ohci_match),
> }
> };
>
> --
> 1.7.0.4
--
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 net-next 4/8] wireless: Use eth_random_addr
On Fri, Jul 13, 2012 at 7:33 AM, Joe Perches wrote: > Convert the existing uses of random_ether_addr to > the new eth_random_addr. > > Signed-off-by: Joe Perches For the rt2x00 parts: Acked-by: Gertjan van Wingerde > --- > drivers/net/wireless/adm8211.c |2 +- > drivers/net/wireless/p54/eeprom.c |2 +- > drivers/net/wireless/rt2x00/rt2400pci.c|2 +- > drivers/net/wireless/rt2x00/rt2500pci.c|2 +- > drivers/net/wireless/rt2x00/rt2500usb.c|2 +- > drivers/net/wireless/rt2x00/rt2800lib.c|2 +- > drivers/net/wireless/rt2x00/rt61pci.c |2 +- > drivers/net/wireless/rt2x00/rt73usb.c |2 +- > drivers/net/wireless/rtl818x/rtl8180/dev.c |2 +- > drivers/net/wireless/rtl818x/rtl8187/dev.c |2 +- > 10 files changed, 10 insertions(+), 10 deletions(-) > --- Gertjan -- 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] acpi : acpi_bus_trim() stops removing devices when failing to remove the device
2012/07/13 1:50, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:28 +0900, Yasuaki Ishimatsu wrote:
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
number. But acpi_bus_remove() cannot return error number correctly.
acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if
device cannot be removed correctly, acpi_bus_trim() ignores and continues to
remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing
devices. Therefore acpi_bus_hot_remove_device() can send "_EJ0" to firmware,
even if the device is running on the system. In this case, the system cannot
work well. So acpi_bus_trim() should check whether device was removed or not
correctly. The patch adds error check into some functions to remove the device.
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/scan.c| 15 ---
drivers/base/dd.c | 22 +-
include/linux/device.h |2 +-
3 files changed, 30 insertions(+), 9 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/scan.c
===
--- linux-3.5-rc6.orig/drivers/acpi/scan.c 2012-07-12 20:11:37.316443808
+0900
+++ linux-3.5-rc6/drivers/acpi/scan.c 2012-07-12 20:17:17.927185231 +0900
@@ -425,12 +425,17 @@ static int acpi_device_remove(struct dev
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = acpi_dev->driver;
+ int ret;
if (acpi_drv) {
if (acpi_drv->ops.notify)
acpi_device_remove_notify_handler(acpi_dev);
- if (acpi_drv->ops.remove)
- acpi_drv->ops.remove(acpi_dev, acpi_dev->removal_type);
+ if (acpi_drv->ops.remove) {
+ ret = acpi_drv->ops.remove(acpi_dev,
+ acpi_dev->removal_type);
+ if (ret)
+ return ret;
+ }
}
acpi_dev->driver = NULL;
acpi_dev->driver_data = NULL;
@@ -1208,11 +1213,15 @@ static int acpi_device_set_context(struc
static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
{
+ int ret;
+
if (!dev)
return -EINVAL;
dev->removal_type = ACPI_BUS_REMOVAL_EJECT;
- device_release_driver(>dev);
+ ret = device_release_driver(>dev);
+ if (ret)
+ return ret;
if (!rmdevice)
return 0;
Index: linux-3.5-rc6/drivers/base/dd.c
===
--- linux-3.5-rc6.orig/drivers/base/dd.c2012-07-12 20:11:37.316443808
+0900
+++ linux-3.5-rc6/drivers/base/dd.c 2012-07-12 20:17:17.928185218 +0900
@@ -464,9 +464,10 @@ EXPORT_SYMBOL_GPL(driver_attach);
* __device_release_driver() must be called with @dev lock held.
* When called for a USB interface, @dev->parent lock must be held as well.
*/
-static void __device_release_driver(struct device *dev)
+static int __device_release_driver(struct device *dev)
{
struct device_driver *drv;
+ int ret;
drv = dev->driver;
if (drv) {
@@ -482,9 +483,11 @@ static void __device_release_driver(stru
pm_runtime_put_sync(dev);
if (dev->bus && dev->bus->remove)
- dev->bus->remove(dev);
+ ret = dev->bus->remove(dev);
else if (drv->remove)
- drv->remove(dev);
+ ret = drv->remove(dev);
+ if (ret)
+ goto rollback;
devres_release_all(dev);
dev->driver = NULL;
klist_remove(>p->knode_driver);
@@ -494,6 +497,12 @@ static void __device_release_driver(stru
dev);
}
+
+ return ret;
ret is uninitialized when !drv.
Thanks! I'll update it.
+
+rollback:
+ driver_sysfs_add(dev);
+ return ret;
}
/**
@@ -503,16 +512,19 @@ static void __device_release_driver(stru
* Manually detach device from driver.
* When called for a USB interface, @dev->parent lock must be held.
*/
-void device_release_driver(struct device *dev)
+int device_release_driver(struct device *dev)
I agree with this change as driver's remove interface can fail.
However, there are other callers to this function, which do not check
the return value. I suppose there is no impact to the other paths since
you only changed the CPU hotplug path to fail properly, but please
confirm this is the case. I recommend documenting this change to the
change log.
Thank you for your agreement. As you know, there are other callers. I
believe the patch does not impact to them, since all of them does not
check return value of device_release_driver().
I will write it to the patch.
Thanks,
Yasuaki Ishimatsu
Thanks,
-Toshi
Re: [Ksummit-2012-discuss] ARM mini-summit
* Kukjin Kim [120712 15:13]: > > +1 same here, I'm interested in ARM mini-summit :) Yeah me too! Tony -- 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: [fuse-devel] [RFC PATCH 0/5] fuse: make maximum read/write request size tunable
Hi Miklos, Thank you for your comments. (2012/07/12 19:13), Miklos Szeredi wrote: HAYASAKA Mitsuo writes: Hi Yuan and Han-Wen, Thank you for your comments. (2012/07/06 22:58), Han-Wen Nienhuys wrote: On Fri, Jul 6, 2012 at 2:53 AM, Liu Yuan wrote: On 07/05/2012 06:50 PM, Mitsuo Hayasaka wrote: One of the ways to solve this is to make them tunable. In this series, the new sysfs parameter max_pages_per_req is introduced. It limits the maximum read/write size in fuse request and it can be changed from 32 to 256 pages in current implementations. When the max_read/max_write mount option is specified, FUSE request size is set per mount. (The size is rounded-up to page size and limited up to max_pages_per_req.) Why maxim 256 pages? If we are here, we can go further: most of object storage system has object size of multiple to dozens of megabytes. So I think probably 1M is too small. Our distribution storage system has 4M per object, so I think at least maxim size could be bigger than 4M. The maximum pipe size on my system is 1M, so if you go beyond that, splicing from the FD won't work. Also, the userspace client must reserve a buffer this size so it can receive a write, which is a waste since most requests are much smaller. I checked the maximum pipe size can be changed using fcntl(2) or /proc/sys/fs/pipe-max-size. It is clear that it is not a fixed value. Also, it seems that there is a request for setting the maximum number of pages per fuse request to 4M (1024 pages). One of the reasons to introduce the sysfs max_pages_per_req parameter is to set a threshold of the maximum number of pages dynamically according to the administrator's demand, and root can only change it. So, when the maximum value is required to be set to not more than the pipe-max-size, the max_pages_per_req should be changed considering it. It seems that the upper limit of this parameter does not have to be not more than it. I'm planning to limit max_pages_per_req up to 1024 pages and add the document to /Documentation/filesystems/fuse.txt, as follows. "the sysfs max_pages_per_req parameter can be changed from 32 to 1024. The default is 32 pages. Generally, the pipe-max-size is 1M (256 pages) and it is better to set it to not more than the pipe-max-size." Can't we just use pipe-max-size for the limit? This is great! I'd like to change this patch to using the pipe-max-size for the upper limit of the max_pages_per_req sysfs paramter, and resubmit it. Then we'll use the minimum of pipe-max-size and max_read/max_write for sizing the requests. Another comment: do we really need to allocate each and every request with space for the pages? I don't think that makes sense. Let's leave some small number of pages inline in the request and allocate a separate array if the number of pages is too large. There may even be some utilities in the kernel to handle dynamically sized page arrays (I haven't looked but I suspect there is). This is interesting and enables to dramatically reduce the number of page allocation and free. However, it seems that it is necessary to investigate if this is feasible. Thanks, Thanks, Miklos -- 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: How to use the generic thermal sysfs.
On Fri, 2012-07-13 at 09:51 +0800, Zhang Rui wrote: > On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote: > > Hi, > > > > > -Original Message- > > > From: Wei Ni [mailto:w...@nvidia.com] > > > Sent: Thursday, July 12, 2012 3:53 PM > > > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; > > > j...@perches.com; R, Durgadoss > > > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > > > acour...@nvidia.com > > > Subject: How to use the generic thermal sysfs. > > > > > > Hi, all > > > I'm working on the tegra thermal throttling upstream issue. > > > The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is > > > the sensor driver. We want to use the generic thermal sysfs. > > > > > > My question is where should we register the thermal zone device? We may > > > have two place to do it: > > > 1. register it in the sensor driver, such as lm90.c > > > In this way, the sensor driver doesn't need to export any APIs, such as > > > get_temp. > > > > This approach is preferred. > > > > > 2. register in my tegra thermal framework. > > > In this way, the sensor driver need to export some APIs, which are used > > > to register the ops and do any other things. > > > > What do you mean by "my tegra thermal framework" ? Where does the source > > file for this sit in the mainline kernel ? > > > I have the same question. > It sounds like that you want to use the tegra thermal framework to do > thermal management instead of the generic thermal layer, right? > > IMO, the purpose of the generic thermal layer is > 1) do kernel thermal management > 2) export unique sysfs I/F to userspace so that users/userspace > applications can take over the thermal management. > > what is the benefit to have another driver to do thermal management in > kernel? > If the current thermal management in the generic thermal layer can not > work well on your platform, it is a good chance to enhance the kernel > thermal manager. :) Our tegra thermal framework also will use the generic thermal layer. It will register the cooling device, and run the throttling in this generic framework. But we have a special mechanism, when the temp is below the trip temp, we will set different cpu capability for different temp range. For example, set the low/high temp as 20C/30C to the sensor, and set the cpu to the max capability, it mean the cpu can run up to the max freq and voltage in this temp range. if the temp is out that range, the sensor will have irq/alert to notify the tegra framework, then we will set to another temperature range and cpu capability. I think we can try to add this mechanism to the generic framework as a new policy, right? > > thanks, > rui > > > > > > > How should I do it? > > > > > > And in current codes, there have the event notification, in the form of > > > a netlink event. But it's difficult to be used in the kernel, it's > > > normally for the communication with user-space. How about to add a > > > notify call chain for it? So when the sensor has irq alert, it can send > > > a notify to my thermal framework in kernel. > > > > We are working on a notification API from any generic sensor driver to > > the thermal framework. > > Please have a look at the 'notify_thermal_framework' API in the patch here: > > http://www.spinics.net/lists/linux-acpi/msg36049.html It's cool. I will cherry pick them to run it. > > > > Thanks, > > Durga > > > > -- 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: resurrecting tcphealth
On Do, 12.07.2012, 23:35, Stephen Hemminger wrote:
> On Thu, 12 Jul 2012 22:55:57 +0200
> "Piotr Sawuk" wrote:
>
>> + * Federico D. Sacerdoti: Added TCP health monitoring.
>
> Please don't do this.
> The kernel community no longer maintains a list of contributors
> in the comments. The history is maintained in the git commit log.
>
thanks for the proof-reading, to Randy Dunlap too. now I have tested the
patch against mainline.
so, anyone has a comment on my actual question about the need for a read-lock?
currently my patch looks like this (again comments are welcome):
diff -rub A/include/linux/tcp.h B/include/linux/tcp.h
--- A/include/linux/tcp.h 2012-06-22 20:37:50.0 +0200
+++ B/include/linux/tcp.h 2012-07-06 10:23:13.0 +0200
@@ -472,6 +474,15 @@
* contains related tcp_cookie_transactions fields.
*/
struct tcp_cookie_values *cookie_values;
+
+ /*
+* TCP health monitoring counters.
+*/
+ __u32 dup_acks_sent;
+ __u32 dup_pkts_recv;
+ __u32 acks_sent;
+ __u32 pkts_recv;
+ __u32 last_ack_sent; /* Sequence number of the last ack we sent. */
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
diff -rub A/net/ipv4/tcp_input.c B/net/ipv4/tcp_input.c
--- A/net/ipv4/tcp_input.c 2012-06-22 20:37:50.0 +0200
+++ B/net/ipv4/tcp_input.c 2012-07-06 10:12:12.0 +0200
@@ -4414,6 +4415,8 @@
}
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
+ /* Course retransmit inefficiency- this packet has been
received twice. */
+ tp->dup_pkts_recv++;
SOCK_DEBUG(sk, "ofo packet was already received\n");
__skb_unlink(skb, >out_of_order_queue);
__kfree_skb(skb);
@@ -4664,6 +4667,10 @@
return;
}
+ /* A packet is a "duplicate" if it contains bytes we have already
received. */
+ if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
+ tp->dup_pkts_recv++;
+
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
/* A retransmit, 2nd most common case. Force an immediate ack.
*/
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_DELAYEDACKLOST);
@@ -5375,6 +5382,13 @@
tp->rx_opt.saw_tstamp = 0;
+ /*
+* Tcp health monitoring is interested in
+* total per-connection packet arrivals.
+* This is in the fast path, but is quick.
+*/
+ tp->pkts_recv++;
+
/* pred_flags is 0xS?10 << 16 + snd_wnd
* if header_prediction is to be made
* 'S' will always be tp->tcp_header_len >> 2
diff -rub A/net/ipv4/tcp_ipv4.c B/net/ipv4/tcp_ipv4.c
--- A/net/ipv4/tcp_ipv4.c 2012-06-22 20:37:50.0 +0200
+++ B/net/ipv4/tcp_ipv4.c 2012-07-11 09:34:22.0 +0200
@@ -2533,6 +2533,82 @@
return 0;
}
+
+/*
+ * Output /proc/net/tcphealth
+ */
+#define LINESZ 128
+
+int tcp_health_seq_show(struct seq_file *seq, void *v)
+{
+ int len, num;
+ char srcIP[32], destIP[32];
+
+ unsigned long SmoothedRttEstimate,
+ AcksSent, DupAcksSent, PktsRecv, DupPktsRecv;
+ struct tcp_iter_state *st;
+
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(seq,
+ "TCP Health Monitoring (established connections only)\n"
+ " -Duplicate ACKs indicate lost or reordered packets on the
connection.\n"
+ " -Duplicate Packets Received signal a slow and badly
inefficient
connection.\n"
+ " -RttEst estimates how long future packets will take on a
round trip
over the connection.\n"
+ "id Local AddressRemote Address RttEst(ms)
AcksSent "
+ "DupAcksSent PktsRecv DupPktsRecv\n");
+ goto out;
+ }
+
+ /* Loop through established TCP connections */
+ st = seq->private;
+
+
+ if (st->state == TCP_SEQ_STATE_ESTABLISHED)
+ {
+/* ; //insert read-lock here */
+ const struct tcp_sock *tp = tcp_sk(v);
+ const struct inet_sock *inet = inet_sk(v);
+ __be32 dest = inet->inet_daddr;
+ __be32 src = inet->inet_rcv_saddr;
+ __u16 destp = ntohs(inet->inet_dport);
+ __u16 srcp = ntohs(inet->inet_sport);
+
+ num = st->num;
+ SmoothedRttEstimate = (tp->srtt >> 3);
+ AcksSent = tp->acks_sent;
+ DupAcksSent = tp->dup_acks_sent;
+ PktsRecv = tp->pkts_recv;
+ DupPktsRecv = tp->dup_pkts_recv;
+
+ sprintf(srcIP, "%lu.%lu.%lu.%lu:%u",
+ ((src >> 24) & 0xFF), ((src >> 16) & 0xFF), ((src >> 8)
& 0xFF), (src &
0xFF),
+ srcp);
+ sprintf(destIP, "%3d.%3d.%3d.%3d:%u",
+
Re: [PATCH] [ARM] Unconditional call to smp_cross_call on UP crashes (take #2)
Hi Pantelis, In case you do not know the process of ARM core patches. You need to put the patch into Russell's patch system [1] after review gets done. Then the patch will show up on Russell's git tree. Regards, Shawn [1] http://www.arm.linux.org.uk/developer/patches/ On Fri, May 25, 2012 at 07:58:36PM +, Pantelis Antoniou wrote: > omap2plus_defconfig builds with SMP & SMP_ON_UP set. > On beagle (which is UP) is_smp() returns false and we don't call > smp_init_cpus which in turn does not initialize smp_cross_call which > remains NULL. > > When issuing a reboot we OOPS with a NULL dereference on stop smp_call. > > Fixed by a check with if (!cpumask_empty()) before issuing the smp > stop cross call. > > Restarting system. > Unable to handle kernel NULL pointer dereference at virtual address > pgd = dda5 > [] *pgd=9e723831, *pte=, *ppte= > Internal error: Oops: 8007 [#1] SMP ARM > Modules linked in: > CPU: 0Not tainted (3.4.0-1-gb15b046 #30) > PC is at 0x0 > LR is at smp_send_stop+0x4c/0xe8 > pc : [<>]lr : []psr: 6013 > sp : de7b5e70 ip : fp : 0001 > r10: r9 : de7b4000 r8 : c07263d0 > r7 : r6 : c06e1294 r5 : 000f4240 r4 : de7b5e74 > r3 : r2 : r1 : 0006 r0 : de7b5e74 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 10c5387d Table: 9da50019 DAC: 0015 > Process reboot (pid: 2229, stack limit = 0xde7b42f8) > Stack: (0xde7b5e70 to 0xde7b6000) > 5e60: 01234567 > 5e80: de7b4000 c001475c 4321fedc c0052570 003e c081db78 003e > 5ea0: 0001 0002 0002 c00891f0 0002 dd5ba0ac 0002 > 5ec0: dd5ba0ac de7b4000 c009eef4 de7b4000 c00f44dc de7b4000 c00f44dc > 5ee0: c0c94d24 de7b4000 0002 0002 c00891f0 > 5f00: 0002 c011286c dd5ba060 6013 > 5f20: dd688d8c de7b4000 c06e20f8 dec14760 dec14750 de7b4000 c06e20f8 > 5f40: 00011f10 c01128a0 0002 c011286c c00fa014 dd8c3180 de7b4000 > 5f60: c0013380 de508bc0 0001 6010 0001 ef00 0001 c0089bfc > 5f80: 0001 0004 0058 0001 0004 0058 > 5fa0: c0013428 c0013260 0001 fee1dead 28121969 01234567 > 5fc0: 0001 0004 0058 0001 0001 0001 > 5fe0: b6e76200 beba4c90 9210 b6e76218 6010 fee1dead > [] (smp_send_stop+0x4c/0xe8) from [] > (machine_restart+0xc/0x54) > [] (machine_restart+0xc/0x54) from [] > (sys_reboot+0x140/0x204) > [] (sys_reboot+0x140/0x204) from [] > (ret_fast_syscall+0x0/0x3c) > Code: bad PC value > ---[ end trace f5035e8726d1f51b ]--- > > Signed-off-by: Pantelis Antoniou > Cc: sta...@vger.kernel.org > --- > arch/arm/kernel/smp.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c > index 8f46446..7babc3f 100644 > --- a/arch/arm/kernel/smp.c > +++ b/arch/arm/kernel/smp.c > @@ -590,7 +590,8 @@ void smp_send_stop(void) > > cpumask_copy(, cpu_online_mask); > cpumask_clear_cpu(smp_processor_id(), ); > - smp_cross_call(, IPI_CPU_STOP); > + if (!cpumask_empty()) > + smp_cross_call(, IPI_CPU_STOP); > > /* Wait up to one second for other CPUs to stop */ > timeout = USEC_PER_SEC; > -- > 1.7.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/ -- 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: How to use the generic thermal sysfs.
On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote: > On Fri, 2012-07-13 at 09:51 +0800, Zhang Rui wrote: > > On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote: > > > Hi, > > > > > > > -Original Message- > > > > From: Wei Ni [mailto:w...@nvidia.com] > > > > Sent: Thursday, July 12, 2012 3:53 PM > > > > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; > > > > kh...@linux-fr.org; > > > > j...@perches.com; R, Durgadoss > > > > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > > > > acour...@nvidia.com > > > > Subject: How to use the generic thermal sysfs. > > > > > > > > Hi, all > > > > I'm working on the tegra thermal throttling upstream issue. > > > > The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is > > > > the sensor driver. We want to use the generic thermal sysfs. > > > > > > > > My question is where should we register the thermal zone device? We may > > > > have two place to do it: > > > > 1. register it in the sensor driver, such as lm90.c > > > > In this way, the sensor driver doesn't need to export any APIs, such as > > > > get_temp. > > > > > > This approach is preferred. > > > > > > > 2. register in my tegra thermal framework. > > > > In this way, the sensor driver need to export some APIs, which are used > > > > to register the ops and do any other things. > > > > > > What do you mean by "my tegra thermal framework" ? Where does the source > > > file for this sit in the mainline kernel ? > > > > > I have the same question. > > It sounds like that you want to use the tegra thermal framework to do > > thermal management instead of the generic thermal layer, right? > > > > IMO, the purpose of the generic thermal layer is > > 1) do kernel thermal management > > 2) export unique sysfs I/F to userspace so that users/userspace > > applications can take over the thermal management. > > > > what is the benefit to have another driver to do thermal management in > > kernel? > > If the current thermal management in the generic thermal layer can not > > work well on your platform, it is a good chance to enhance the kernel > > thermal manager. :) > > Our tegra thermal framework also will use the generic thermal layer. It > will register the cooling device, and run the throttling in this generic > framework. > But we have a special mechanism, when the temp is below the trip temp, > we will set different cpu capability for different temp range. For > example, set the low/high temp as 20C/30C to the sensor, and set the cpu > to the max capability, it mean the cpu can run up to the max freq and > voltage in this temp range. if the temp is out that range, the sensor > will have irq/alert to notify the tegra framework, then we will set to > another temperature range and cpu capability. > I think we can try to add this mechanism to the generic framework as a > new policy, right? > I think you can make use of the upper limit in my patch set. Say, here is your thermal policy 20C - 30C, P0 30C - 40C, P1 - P2 40C - 60C, P3 - P5 60C+, P6 ~ Pn you can register to the thermal layer 4 passive trip points, 20C, 30C, 40C, 60C, and then 1) for trip 0 (20C), upper limit 0, lower limit 0 2) for trip 1 (30C), upper limit 2, lower limit 1 3) for trip 2 (40C), upper limit 5, lower limit 3 4) for trip 3 (60C), upper limit n, lower limit 6 you can program your own sensor to get interrupt when the temperature hits 20C/30C/40C/60C, and the generic thermal layer will put the processors to proper frequency for each trip point. what do you think? BTW, the upper and lower limit is introduced in the patch set I'm testing, so maybe you were not aware of it. thanks, rui > > > > thanks, > > rui > > > > > > > > > > How should I do it? > > > > > > > > And in current codes, there have the event notification, in the form of > > > > a netlink event. But it's difficult to be used in the kernel, it's > > > > normally for the communication with user-space. How about to add a > > > > notify call chain for it? So when the sensor has irq alert, it can send > > > > a notify to my thermal framework in kernel. > > > > > > We are working on a notification API from any generic sensor driver to > > > the thermal framework. > > > Please have a look at the 'notify_thermal_framework' API in the patch > > > here: > > > http://www.spinics.net/lists/linux-acpi/msg36049.html > > It's cool. I will cherry pick them to run it. > > > > > > > Thanks, > > > Durga > > > > > > > > > -- 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] Input updates for 3.5-rc6
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. The changes are limited to adding new VID/PID combinations to drivers to enable support for new versions of hardware, most notably hardware found in new MacBook Pro Retina boxes. Changelog: - Henrik Rydberg (1): Input: bcm5974 - Add support for 2012 MacBook Pro Retina Ilia Katsnelson (1): Input: xpad - add signature for Razer Onza Tournament Edition Ryan Bourgeois (1): HID: add support for 2012 MacBook Pro Retina Yuri Khan (2): Input: xpad - handle all variations of Mad Catz Beat Pad Input: xpad - add Andamiro Pump It Up pad Diffstat: drivers/hid/hid-apple.c |6 ++ drivers/hid/hid-core.c|7 +++ drivers/hid/hid-ids.h |6 ++ drivers/input/joystick/xpad.c |6 +- drivers/input/mouse/bcm5974.c | 20 5 files changed, 44 insertions(+), 1 deletion(-) -- Dmitry pgp7p4r9aTt5K.pgp Description: PGP signature
[PATCH] MIPS: BCM63XX: select HAVE_CLK
BCM63XX implements the clk interface, but does not advertise it.
Signed-off-by: Jonas Gorski
---
This fixes a build failure in linux-next caused by
5afae362dc79cb8b6b3965422d13d118c63d4ee4 ("clk: Add non CONFIG_HAVE_CLK
routines"):
CC arch/mips/bcm63xx/clk.o
arch/mips/bcm63xx/clk.c:285:5: error: redefinition of 'clk_enable'
include/linux/clk.h:294:19: note: previous definition of 'clk_enable' was here
and so on (I think you have already seen one of these).
@Andrew: This patch should apply cleanly to any tree, so maybe you
could add it to your patch series in front of the mentioned
patch, to keep bisectability for bcm63xx.
@Ralf: I hope it is okay for you that this goes through a different
tree.
arch/mips/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 09ab87e..80d9199 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -122,6 +122,7 @@ config BCM63XX
select SYS_HAS_EARLY_PRINTK
select SWAP_IO_SPACE
select ARCH_REQUIRE_GPIOLIB
+ select HAVE_CLK
help
Support for BCM63XX based boards
--
1.7.2.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: [PATCH v3] ext4: fix hole punch failure when depth is greater than 0
Hi Ted,
Did you get time to check this patch?
If possible, can you collect the patch from the last sent mail?
On Tue, Jul 10, 2012 at 9:56 PM, Ashish Sangwan
wrote:
> Whether to continue removing extents or not is decided by the return value
> of function ext4_ext_more_to_rm() which checks 2 conditions:
> a) if there are no more indexes to process.
> b) if the number of entries are decreased in the header of "depth -1".
>
> In case of hole punch, if the last block to be removed is not part of the
> last extent index than this index will not be deleted, hence the number of
> valid entries in the extent header of "depth - 1" will remain as it is and
> ext4_ext_more_to_rm will return 0 although the required blocks are not
> yet removed.
>
> This patch fixes the above mentioned problem as instead of removing the
> extents from the end of file, it starts removing the blocks from the
> particular extent from which removing blocks is actually required and
> continue backward until done.
>
> Signed-off-by: Ashish Sangwan
> Signed-off-by: Namjae Jeon
> Reviewed-by: Lukas Czerner
> ---
> fs/ext4/extents.c | 46 +-
> 1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 91341ec..45ac45d 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -2570,10 +2570,10 @@ static int ext4_ext_remove_space(struct inode *inode,
> ext4_lblk_t start,
> {
> struct super_block *sb = inode->i_sb;
> int depth = ext_depth(inode);
> - struct ext4_ext_path *path;
> + struct ext4_ext_path *path = NULL;
> ext4_fsblk_t partial_cluster = 0;
> handle_t *handle;
> - int i, err;
> + int i = 0, err;
>
> ext_debug("truncate since %u to %u\n", start, end);
>
> @@ -2606,8 +2606,12 @@ again:
> }
> depth = ext_depth(inode);
> ex = path[depth].p_ext;
> - if (!ex)
> + if (!ex) {
> + ext4_ext_drop_refs(path);
> + kfree(path);
> + path = NULL;
> goto cont;
> + }
>
> ee_block = le32_to_cpu(ex->ee_block);
>
> @@ -2637,8 +2641,6 @@ again:
> if (err < 0)
> goto out;
> }
> - ext4_ext_drop_refs(path);
> - kfree(path);
> }
> cont:
>
> @@ -2647,19 +2649,27 @@ cont:
> * after i_size and walking into the tree depth-wise.
> */
> depth = ext_depth(inode);
> - path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 1), GFP_NOFS);
> - if (path == NULL) {
> - ext4_journal_stop(handle);
> - return -ENOMEM;
> - }
> - path[0].p_depth = depth;
> - path[0].p_hdr = ext_inode_hdr(inode);
> + if (path) {
> + int k = i = depth;
> + while (--k > 0)
> + path[k].p_block =
> + le16_to_cpu(path[k].p_hdr->eh_entries)+1;
> + } else {
> + path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 1),
> + GFP_NOFS);
> + if (path == NULL) {
> + ext4_journal_stop(handle);
> + return -ENOMEM;
> + }
> + path[0].p_depth = depth;
> + path[0].p_hdr = ext_inode_hdr(inode);
>
> - if (ext4_ext_check(inode, path[0].p_hdr, depth)) {
> - err = -EIO;
> - goto out;
> + if (ext4_ext_check(inode, path[0].p_hdr, depth)) {
> + err = -EIO;
> + goto out;
> + }
> }
> - i = err = 0;
> + err = 0;
>
> while (i >= 0 && err == 0) {
> if (i == depth) {
> @@ -2773,8 +2783,10 @@ cont:
> out:
> ext4_ext_drop_refs(path);
> kfree(path);
> - if (err == -EAGAIN)
> + if (err == -EAGAIN) {
> + path = NULL;
> goto again;
> + }
> ext4_journal_stop(handle);
>
> return err;
> --
> 1.7.10.4
>
--
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: UIO: missing resource mapping
Am Freitag, den 13.07.2012, 02:16 +0300 schrieb Michael S. Tsirkin: > My concern was people will ask for more and more stuff that pci > sysfs already has. > If we do add these is there a way to not duplicate code from pci? I have some concerns about the placing for the BAR mapping code inside the kernel. The point is, that sysfs currently makes it possible to map BARs of all card which are handled by any driver. This is fine in case of UIO, because it is intended that a user-space program maps BARs, but it is also possible to map BARs that are already handle by a kernel driver. It i therefore possible to jam the system by confusing sysfs entries. I don't know which implications this has, but I would move the BAR mapping capabilities completely to UIO. This should ensure that only BARs can be mapped, which are handled by UIO and no other kernel-space driver. -- Gruß Dominic Frankfurt Institute for Advanced Studies (FIAS) Ruth-Moufang-Straße 1 D-60438 Frankfurt am Main Germany Phone: +49 69 79844114 -- 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] dw_dmac: use 'u32' for LLI structure members, not dma_addr_t
Use 'u32' for the LLI structure members, which are defined by hardware to be
32-bit. dma_addr_t is much more vague about its actual size.
Signed-off-by: Andy Shevchenko
---
drivers/dma/dw_dmac.c |7 ++-
drivers/dma/dw_dmac_regs.h |6 +++---
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index db56ef4..3d061c6 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -416,11 +416,8 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct
dw_dma_chan *dwc)
static inline void dwc_dump_lli(struct dw_dma_chan *dwc, struct dw_lli *lli)
{
dev_printk(KERN_CRIT, chan2dev(>chan),
- " desc: s0x%llx d0x%llx l0x%llx c0x%x:%x\n",
- (unsigned long long)lli->sar,
- (unsigned long long)lli->dar,
- (unsigned long long)lli->llp,
- lli->ctlhi, lli->ctllo);
+ " desc: s0x%x d0x%x l0x%x c0x%x:%x\n",
+ lli->sar, lli->dar, lli->llp, lli->ctlhi, lli->ctllo);
}
static void dwc_handle_error(struct dw_dma *dw, struct dw_dma_chan *dwc)
diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
index e248481..50830be 100644
--- a/drivers/dma/dw_dmac_regs.h
+++ b/drivers/dma/dw_dmac_regs.h
@@ -219,9 +219,9 @@ static inline struct dw_dma *to_dw_dma(struct dma_device
*ddev)
/* LLI == Linked List Item; a.k.a. DMA block descriptor */
struct dw_lli {
/* values that are not changed by hardware */
- dma_addr_t sar;
- dma_addr_t dar;
- dma_addr_t llp;/* chain to next lli */
+ u32 sar;
+ u32 dar;
+ u32 llp;/* chain to next lli */
u32 ctllo;
/* values that may get written back: */
u32 ctlhi;
--
1.7.10.4
--
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] dw_dmac: mark dwc_dump_lli inline
Signed-off-by: Andy Shevchenko
---
drivers/dma/dw_dmac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 9151511..db56ef4 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -413,7 +413,7 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct
dw_dma_chan *dwc)
spin_unlock_irqrestore(>lock, flags);
}
-static void dwc_dump_lli(struct dw_dma_chan *dwc, struct dw_lli *lli)
+static inline void dwc_dump_lli(struct dw_dma_chan *dwc, struct dw_lli *lli)
{
dev_printk(KERN_CRIT, chan2dev(>chan),
" desc: s0x%llx d0x%llx l0x%llx c0x%x:%x\n",
--
1.7.10.4
--
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] dw_dmac: set default alignment
The default values are filled to support at least mem-to-mem tests provided by dmatest module. It makes sense to choose the 4 bytes (2 least significant bits) alignment by the default. Signed-off-by: Andy Shevchenko --- drivers/dma/dw_dmac.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c index 3d061c6..2a19ab6 100644 --- a/drivers/dma/dw_dmac.c +++ b/drivers/dma/dw_dmac.c @@ -1485,6 +1485,12 @@ static int __devinit dw_probe(struct platform_device *pdev) dw->dma.device_tx_status = dwc_tx_status; dw->dma.device_issue_pending = dwc_issue_pending; + /* Set default alignment */ + dw->dma.copy_align = 2; + dw->dma.xor_align = 2; + dw->dma.pq_align = 2; + dw->dma.fill_align = 2; + dma_writel(dw, CFG, DW_CFG_DMA_EN); printk(KERN_INFO "%s: DesignWare DMA Controller, %d channels\n", -- 1.7.10.4 -- 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: How to use the generic thermal sysfs.
On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote: > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote: > > Our tegra thermal framework also will use the generic thermal layer. It > > will register the cooling device, and run the throttling in this generic > > framework. > > But we have a special mechanism, when the temp is below the trip temp, > > we will set different cpu capability for different temp range. For > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu > > to the max capability, it mean the cpu can run up to the max freq and > > voltage in this temp range. if the temp is out that range, the sensor > > will have irq/alert to notify the tegra framework, then we will set to > > another temperature range and cpu capability. > > I think we can try to add this mechanism to the generic framework as a > > new policy, right? > > > I think you can make use of the upper limit in my patch set. > Say, here is your thermal policy > 20C - 30C, P0 > 30C - 40C, P1 - P2 > 40C - 60C, P3 - P5 > 60C+, P6 ~ Pn > > you can register to the thermal layer 4 passive trip points, > 20C, 30C, 40C, 60C, and then > 1) for trip 0 (20C), upper limit 0, lower limit 0 > 2) for trip 1 (30C), upper limit 2, lower limit 1 > 3) for trip 2 (40C), upper limit 5, lower limit 3 > 4) for trip 3 (60C), upper limit n, lower limit 6 > > you can program your own sensor to get interrupt when the temperature > hits 20C/30C/40C/60C, and the generic thermal layer will put the > processors to proper frequency for each trip point. > > what do you think? It's great, this is exactly what we need. I think for these trip points, we can use a new trip type, such as TRIP_LIMIT, and use new policy. Because in these state, we only need to set the processors to proper frequency capability, it's not like the passive type, the currently passive type will try to set cooling device state continually. And for these trip temp, it's better to add hysteresis value, so that it can avoid unnecessary interrupt. > > BTW, the upper and lower limit is introduced in the patch set I'm > testing, so maybe you were not aware of it. How can I get these codes? > > thanks, > rui -- 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 5/5] uprobes: kill insert_vm_struct()->uprobe_mmap()
* Oleg Nesterov [2012-07-08 22:30:11]:
> Kill insert_vm_struct()->uprobe_mmap(). It is not needed, nobody
> except arch/ia64/kernel/perfmon.c uses insert_vm_struct(vma) with
> vma->vm_file != NULL.
>
Right, but somebody else might start using this later.
I cant think of a use case though.
> And it is wrong. Again, get_user_pages() can not succeed before
> vma_link(vma) makes is visible to find_vma(). And even if this
> worked, we must not insert the new bp before this mapping is
> visible to vma_prio_tree_foreach() for uprobe_unregister().
>
Agree, we are wrong to do it before vma_link.
> Signed-off-by: Oleg Nesterov
> ---
> mm/mmap.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index e5a4614..4fe2697 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2345,9 +2345,6 @@ int insert_vm_struct(struct mm_struct * mm, struct
> vm_area_struct * vma)
>security_vm_enough_memory_mm(mm, vma_pages(vma)))
> return -ENOMEM;
>
> - if (vma->vm_file && uprobe_mmap(vma))
> - return -EINVAL;
> -
> vma_link(mm, vma, prev, rb_link, rb_parent);
> return 0;
> }
Can we do something like:
vma_link(mm, vma, prev, rb_link, rb_parent);
if (vma->vm_file && uprobe_mmap(vma)) {
/* FIXME: dont know if calling unmap_region is fine here */
unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
return -EINVAL;
}
return 0;
}
--
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 00/12] ACPI: add module_acpi_driver() and convert drivers to it
On Thu, Jun 28, 2012 at 01:59:19PM +0300, Mika Westerberg wrote: > This is similar than what is done for other busses before (PCI, I2C, SPI, > platform). It reduces a lot of unnecessary boilerplate code from modules. > > We also remove following redundant check on few drivers: > > if (acpi_disabled) > return -ENODEV; > > as this same check is already done at the beginning of > acpi_bus_register_driver(). > > I think these should all go via ACPI tree because they all depend on the > first patch which adds the macro to the ACPI subsystem. Len, do you have any comments? Could you consider merging these patches? 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/
Re: [PATCH 4/5] uprobes: kill copy_vma()->uprobe_mmap()
* Oleg Nesterov [2012-07-08 22:30:08]:
> Kill copy_vma()->uprobe_mmap(new_vma), it is absolutely wrong.
>
> This new_vma was just initialized to represent the new unmapped area,
> [vm_start, vm_end) was returned by get_unmapped_area() in the caller.
>
> This means that uprobe_mmap()->get_user_pages() will fail for sure,
> simply because find_vma() can never succeed. And I verified that
> sys_mremap()->mremap_to() indeed always fails with the wrong ENOMEM
> code if [addr, addr+old_len] is probed.
>
> And why this uprobe_mmap() was added? I believe the intent was wrong.
> Note that the caller is going to do move_page_tables(), all registered
> uprobes are already faulted in, we only change the virtual addresses.
>
> NOTE: However, somehow we need to close the race with uprobe_register()
> which relies on map_info->vaddr. This needs another fix I'll try to do
> later. Probably we need uprobe_mmap() in move_vma() but we can not do
> this right now, this can confuse uprobes_state.counter (which I still
> hope we are going to kill).
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
> mm/mmap.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 3edfcdf..e5a4614 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2418,9 +2418,6 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
> **vmap,
> if (new_vma->vm_file) {
> get_file(new_vma->vm_file);
>
> - if (uprobe_mmap(new_vma))
> - goto out_free_mempol;
> -
> if (vma->vm_flags & VM_EXECUTABLE)
> added_exe_file_vma(mm);
> }
> --
> 1.5.5.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 v2 -mm] memcg: prevent from OOM with too many dirty pages
On Thu 12-07-12 15:42:53, Hugh Dickins wrote: > On Thu, 12 Jul 2012, Andrew Morton wrote: > > On Thu, 12 Jul 2012 09:05:01 +0200 > > Michal Hocko wrote: > > > > > When we are back to the patch. Is it going into 3.5? I hope so and I > > > think it is really worth stable as well. Andrew? > > > > What patch. "memcg: prevent OOM with too many dirty pages"? > > Yes. > > > > > I wasn't planning on 3.5, given the way it's been churning around. > > I don't know if you had been intending to send it in for 3.5 earlier; > but I'm sorry if my late intervention on may_enter_fs has delayed it. Well I should investigate more when the question came up... > > How about we put it into 3.6 and tag it for a -stable backport, so > > it gets a bit of a run in mainline before we inflict it upon -stable > > users? > > That sounds good enough to me, but does fall short of Michal's hope. I would be happier if it went into 3.5 already because the problem (OOM on too many dirty pages) is real and long term (basically since ever). We have the patch in SLES11-SP2 for quite some time (the original one with the may_enter_fs check) and it helped a lot. The patch was designed as a band aid primarily because it is very simple that way and with a hope that the real fix will come later. The decision is up to you Andrew, but I vote for pushing it as soon as possible and try to come up with something more clever for 3.6. > > Hugh -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- 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/
[3.5-rc6+] Re: ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume
Hi, looks like [1] is fixing my suspend/resume problem with v3.5-rc6+ (attached call-trace is with a v3.5-rc6 kernel before the commit got upstream). Thanks for the fix! I am wondering if those new-lines are intended (see attachment)? - Sedat - P.S.: Commit details commit dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a [17043.897493] wlan0: deauthenticating from 00:04:0e:e4:00:3d by local choice (reason=3) [17043.908296] cfg80211: All devices are disconnected, going to restore regulatory settings [17043.908305] cfg80211: Restoring regulatory settings [17043.908313] cfg80211: Calling CRDA to update world regulatory domain [17043.915387] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain [17043.915395] cfg80211: World regulatory domain updated: [17043.915398] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [17043.915402] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [17043.915407] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [17043.915410] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [17043.915413] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [17043.915417] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [17045.745718] PM: Syncing filesystems ... done. [17045.749964] PM: Preparing system for mem sleep [17046.303388] Freezing user space processes ... (elapsed 0.01 seconds) done. [17046.319432] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [17046.335421] PM: Entering mem sleep [17046.335491] Suspending console(s) (use no_console_suspend to debug) [17046.335698] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [17046.335869] sd 0:0:0:0: [sda] Synchronizing SCSI cache [17046.336017] sd 0:0:0:0: [sda] Stopping disk [17046.338588] sd 1:0:0:0: [sdb] Stopping disk [17046.348401] [ cut here ] [17046.348408] WARNING: at kernel/irq/manage.c:1214 __free_irq+0xa0/0x1d0() [17046.348409] Hardware name: [17046.348410] Trying to free already-free IRQ 47 [17046.348410] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek rfcomm bnep parport_pc ppdev joydev snd_hda_intel snd_hda_codec snd_hwdep snd_pcm coretemp kvm_intel snd_page_alloc kvm arc4 snd_seq_midi snd_seq_midi_event iwlwifi i915 snd_rawmidi uvcvideo snd_seq ghash_clmulni_intel snd_seq_device videobuf2_vmalloc aesni_intel snd_timer videobuf2_memops aes_x86_64 drm_kms_helper videobuf2_core cryptd mac80211 drm snd videodev psmouse samsung_laptop i2c_algo_bit btusb hid_generic soundcore microcode serio_raw cfg80211 lp mei bluetooth video mac_hid lpc_ich parport usbhid hid r8169 [17046.348441] Pid: 18981, comm: kworker/u:17 Not tainted 3.5.0-rc6-1-iniza-generic #1 [17046.348442] Call Trace: [17046.348444] [17046.348447] [] warn_slowpath_common+0x7f/0xc0 [17046.348448] [17046.348449] [] warn_slowpath_fmt+0x46/0x50 [17046.348450] [17046.348452] [] ? default_spin_lock_flags+0x9/0x10 [17046.348453] [17046.348455] [] __free_irq+0xa0/0x1d0 [17046.348455] [17046.348460] [] ? async_schedule+0x20/0x20 [17046.348460] [17046.348462] [] free_irq+0x55/0xd0 [17046.348463] [17046.348467] [] mei_pci_suspend+0x78/0xd0 [mei] [17046.348468] [17046.348471] [] pci_pm_suspend+0x75/0x140 [17046.348472] [17046.348475] [] ? device_pm_wait_for_dev+0x30/0x30 [17046.348475] [17046.348477] [] ? pci_pm_freeze+0xb0/0xb0 [17046.348477] [17046.348478] [] dpm_run_callback.isra.5+0x3b/0x80 [17046.348479] [17046.348480] [] __device_suspend+0xed/0x220 [17046.348481] [17046.348482] [] async_suspend+0x1f/0xa0 [17046.348482] [17046.348484] [] async_run_entry_fn+0x7e/0x170 [17046.348484] [17046.348488] [] process_one_work+0x11a/0x480 [17046.348488] [17046.348490] [] ? manage_workers.isra.28+0x1e8/0x230 [17046.348491] [17046.348493] [] worker_thread+0x165/0x370 [17046.348493] [17046.348495] [] ? manage_workers.isra.28+0x230/0x230 [17046.348496] [17046.348498] [] kthread+0x93/0xa0 [17046.348498] [17046.348500] [] kernel_thread_helper+0x4/0x10 [17046.348501] [17046.348503] [] ? kthread_freezable_should_stop+0x70/0x70 [17046.348503] [17046.348504] [] ? gs_change+0x13/0x13 [17046.348506] ---[ end trace 595e5069309213b1 ]--- [17046.927294] PM: suspend of devices complete after 591.818 msecs [17046.927296] PM: suspend devices took 0.592 seconds [17046.927414] PM: late suspend of devices complete after 0.116 msecs [17046.943325] r8169 :02:00.0: wake-up capability enabled by ACPI [17047.023288] PM: noirq suspend of devices complete after 95.890 msecs [17047.023520] ACPI: Preparing to enter system sleep state S3 [17047.047343] PM: Saving platform NVS memory [17047.052086] Disabling non-boot CPUs ...
Re: [PATCH 3/3] dw_dmac: set default alignment
It would be nice to keep spear-devel in cc, as this is the second platform that uses this driver. On Fri, Jul 13, 2012 at 9:09 AM, Andy Shevchenko wrote: > The default values are filled to support at least mem-to-mem tests provided by > dmatest module. It makes sense to choose the 4 bytes (2 least significant > bits) > alignment by the default. > > Signed-off-by: Andy Shevchenko > --- > drivers/dma/dw_dmac.c |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c > index 3d061c6..2a19ab6 100644 > --- a/drivers/dma/dw_dmac.c > +++ b/drivers/dma/dw_dmac.c > @@ -1485,6 +1485,12 @@ static int __devinit dw_probe(struct platform_device > *pdev) > dw->dma.device_tx_status = dwc_tx_status; > dw->dma.device_issue_pending = dwc_issue_pending; > > + /* Set default alignment */ > + dw->dma.copy_align = 2; > + dw->dma.xor_align = 2; > + dw->dma.pq_align = 2; > + dw->dma.fill_align = 2; To understand it more, what does this mean? We will not support transfers with unaligned addresses/length to word size? -- viresh -- 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] dw_dmac: mark dwc_dump_lli inline
On Fri, Jul 13, 2012 at 9:09 AM, Andy Shevchenko
wrote:
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 9151511..db56ef4 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -413,7 +413,7 @@ static void dwc_scan_descriptors(struct dw_dma *dw,
> struct dw_dma_chan *dwc)
> spin_unlock_irqrestore(>lock, flags);
> }
>
> -static void dwc_dump_lli(struct dw_dma_chan *dwc, struct dw_lli *lli)
> +static inline void dwc_dump_lli(struct dw_dma_chan *dwc, struct dw_lli *lli)
> {
> dev_printk(KERN_CRIT, chan2dev(>chan),
> " desc: s0x%llx d0x%llx l0x%llx c0x%x:%x\n",
Acked-by: Viresh Kumar
--
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] dw_dmac: use 'u32' for LLI structure members, not dma_addr_t
On Fri, Jul 13, 2012 at 9:09 AM, Andy Shevchenko
wrote:
> Use 'u32' for the LLI structure members, which are defined by hardware to be
> 32-bit. dma_addr_t is much more vague about its actual size.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |7 ++-
> drivers/dma/dw_dmac_regs.h |6 +++---
> 2 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index db56ef4..3d061c6 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -416,11 +416,8 @@ static void dwc_scan_descriptors(struct dw_dma *dw,
> struct dw_dma_chan *dwc)
> static inline void dwc_dump_lli(struct dw_dma_chan *dwc, struct dw_lli *lli)
> {
> dev_printk(KERN_CRIT, chan2dev(>chan),
> - " desc: s0x%llx d0x%llx l0x%llx c0x%x:%x\n",
> - (unsigned long long)lli->sar,
> - (unsigned long long)lli->dar,
> - (unsigned long long)lli->llp,
> - lli->ctlhi, lli->ctllo);
> + " desc: s0x%x d0x%x l0x%x c0x%x:%x\n",
> + lli->sar, lli->dar, lli->llp, lli->ctlhi, lli->ctllo);
> }
>
> static void dwc_handle_error(struct dw_dma *dw, struct dw_dma_chan *dwc)
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index e248481..50830be 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -219,9 +219,9 @@ static inline struct dw_dma *to_dw_dma(struct dma_device
> *ddev)
> /* LLI == Linked List Item; a.k.a. DMA block descriptor */
> struct dw_lli {
> /* values that are not changed by hardware */
> - dma_addr_t sar;
> - dma_addr_t dar;
> - dma_addr_t llp;/* chain to next lli */
> + u32 sar;
> + u32 dar;
> + u32 llp;/* chain to next lli */
> u32 ctllo;
> /* values that may get written back: */
> u32 ctlhi;
Acked-by: Viresh Kumar
--
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: MAINTAINERS: bounces, remove or update?
Hi Joe, > On 13 July 2012 07:13, Joe Perches wrote: > > The @smsc.com email address is bouncing. > Should it be removed from MAINTAINERS or switched to this > @shawell.net address? It should be changed, I posted a patch to do this back in April - I guess it didn't get picked up. Did I need to CC someone else? https://lkml.org/lkml/2012/4/16/155 Steve -- 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] MIPS: BCM63XX: select HAVE_CLK
On 13/07/12 08:58, Jonas Gorski wrote:
> BCM63XX implements the clk interface, but does not advertise it.
>
> Signed-off-by: Jonas Gorski
> ---
>
> This fixes a build failure in linux-next caused by
> 5afae362dc79cb8b6b3965422d13d118c63d4ee4 ("clk: Add non CONFIG_HAVE_CLK
> routines"):
>
> CC arch/mips/bcm63xx/clk.o
> arch/mips/bcm63xx/clk.c:285:5: error: redefinition of 'clk_enable'
> include/linux/clk.h:294:19: note: previous definition of 'clk_enable' was here
>
> and so on (I think you have already seen one of these).
>
> @Andrew: This patch should apply cleanly to any tree, so maybe you
> could add it to your patch series in front of the mentioned
> patch, to keep bisectability for bcm63xx.
>
> @Ralf: I hope it is okay for you that this goes through a different
> tree.
>
> arch/mips/Kconfig |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 09ab87e..80d9199 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -122,6 +122,7 @@ config BCM63XX
> select SYS_HAS_EARLY_PRINTK
> select SWAP_IO_SPACE
> select ARCH_REQUIRE_GPIOLIB
> + select HAVE_CLK
> help
>Support for BCM63XX based boards
Reviewed-by: Viresh Kumar
--
Viresh
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
--
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/
[Xen-devel] [PATCH-v2] xen: populate correct number of pages when across mem boundary
When populate pages across a mem boundary at bootup, the page count
populated isn't correct. This is due to mem populated to non-mem
region and ignored.
Pfn range is also wrongly aligned when mem boundary isn't page aligned.
-v2: If xen_do_chunk fail(populate), abort this chunk and any others.
Suggested by David, thanks.
For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff is:
[0.00] Freeing 9e-100 pfn range: 98 pages freed
[0.00] 1-1 mapping on 9e->100
[0.00] 1-1 mapping on cd9ff->10
[0.00] Released 98 pages of unused memory
[0.00] Set 206435 page(s) to 1-1 mapping
-[0.00] Populating cd9fe-cda00 pfn range: 1 pages added
+[0.00] Populating cd9fe-cd9ff pfn range: 1 pages added
+[0.00] Populating 10-100061 pfn range: 97 pages added
[0.00] BIOS-provided physical RAM map:
[0.00] Xen: - 0009e000 (usable)
[0.00] Xen: 000a - 0010 (reserved)
[0.00] Xen: 0010 - cd9ff000 (usable)
[0.00] Xen: cd9ffc00 - cda53c00 (ACPI NVS)
...
[0.00] Xen: 0001 - 000100061000 (usable)
[0.00] Xen: 000100061000 - 00012c00 (unusable)
...
[0.00] MEMBLOCK configuration:
...
-[0.00] reserved[0x4] [0x00cd9ff000-0x00cd9ffbff], 0xc00
bytes
-[0.00] reserved[0x5] [0x01-0x0100060fff],
0x61000 bytes
Related xen memory layout:
(XEN) Xen-e820 RAM map:
(XEN) - 0009ec00 (usable)
(XEN) 000f - 0010 (reserved)
(XEN) 0010 - cd9ffc00 (usable)
Signed-off-by: Zhenzhong Duan
---
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a4790bf..ead8557 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -157,25 +157,24 @@ static unsigned long __init xen_populate_chunk(
unsigned long dest_pfn;
for (i = 0, entry = list; i< map_size; i++, entry++) {
- unsigned long credits = credits_left;
unsigned long s_pfn;
unsigned long e_pfn;
unsigned long pfns;
long capacity;
- if (credits<= 0)
+ if (credits_left<= 0)
break;
if (entry->type != E820_RAM)
continue;
- e_pfn = PFN_UP(entry->addr + entry->size);
+ e_pfn = PFN_DOWN(entry->addr + entry->size);
/* We only care about E820 after the xen_start_info->nr_pages */
if (e_pfn<= max_pfn)
continue;
- s_pfn = PFN_DOWN(entry->addr);
+ s_pfn = PFN_UP(entry->addr);
/* If the E820 falls within the nr_pages, we want to start
* at the nr_pages PFN.
* If that would mean going past the E820 entry, skip it
@@ -184,23 +183,19 @@ static unsigned long __init xen_populate_chunk(
capacity = e_pfn - max_pfn;
dest_pfn = max_pfn;
} else {
- /* last_pfn MUST be within E820_RAM regions */
- if (*last_pfn&& e_pfn>= *last_pfn)
- s_pfn = *last_pfn;
capacity = e_pfn - s_pfn;
dest_pfn = s_pfn;
}
- /* If we had filled this E820_RAM entry, go to the next one. */
- if (capacity<= 0)
- continue;
- if (credits> capacity)
- credits = capacity;
+ if (credits_left< capacity)
+ capacity = credits_left;
- pfns = xen_do_chunk(dest_pfn, dest_pfn + credits, false);
+ pfns = xen_do_chunk(dest_pfn, dest_pfn + capacity, false);
done += pfns;
- credits_left -= pfns;
*last_pfn = (dest_pfn + pfns);
+ if (pfns< capacity)
+ break;
+ credits_left -= pfns;
}
return done;
}
--
1.7.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] i2c-s3c2410: Fix pointer type passed to of_match_node()
On Wed, May 30, 2012 at 11:43:05AM +0200, Karol Lewandowski wrote:
> This commit fixes warning introduced in 27452498a ("i2c-s3c2410: Rework
> device type handling"):
>
> drivers/i2c/busses/i2c-s3c2410.c: In function 's3c24xx_get_device_quirks':
> drivers/i2c/busses/i2c-s3c2410.c:125: warning: passing argument 1 of
> 'of_match_node' from incompatible pointer type
> include/linux/of.h:245: note: expected 'const struct of_device_id *' but
> argument is of type 'const struct of_device_id (*)[4]'
>
> Signed-off-by: Karol Lewandowski
> Signed-off-by: Kyungmin Park
Sorry, this dropped of the pile. Applied to next now.
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
[PATCH V3 0/3] Improve virtio-blk performance
This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% 2) Fusion IO device With bio-based IO path, sequential read/write, random read/write IOPS boost : 11%, 11%, 13%, 10% Latency improvement: 10%, 10%, 12%, 10% Asias He (3): block: Introduce __blk_segment_map_sg() helper block: Add blk_bio_map_sg() helper virtio-blk: Add bio-based IO path for virtio-blk block/blk-merge.c | 117 + drivers/block/virtio_blk.c | 203 +++- include/linux/blkdev.h |2 + 3 files changed, 247 insertions(+), 75 deletions(-) -- 1.7.10.4 -- 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] virtio-blk: Add bio-based IO path for virtio-blk
This patch introduces bio-based IO path for virtio-blk. Compared to request-based IO path, bio-based IO path uses driver provided ->make_request_fn() method to bypasses the IO scheduler. It handles the bio to device directly without allocating a request in block layer. This reduces the IO path in guest kernel to achieve high IOPS and lower latency. The downside is that guest can not use the IO scheduler to merge and sort requests. However, this is not a big problem if the backend disk in host side uses faster disk device. When the bio-based IO path is not enabled, virtio-blk still uses the original request-based IO path, no performance difference is observed. Performance evaluation: - 1) Fio test is performed in a 8 vcpu guest with ramdisk based guest using kvm tool. Short version: With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% Long version: With bio-based IO path: seq-read : io=2048.0MB, bw=116996KB/s, iops=233991 , runt= 17925msec seq-write : io=2048.0MB, bw=100829KB/s, iops=201658 , runt= 20799msec rand-read : io=3095.7MB, bw=112134KB/s, iops=224268 , runt= 28269msec rand-write: io=3095.7MB, bw=96198KB/s, iops=192396 , runt= 32952msec clat (usec): min=0 , max=2631.6K, avg=58716.99, stdev=191377.30 clat (usec): min=0 , max=1753.2K, avg=66423.25, stdev=81774.35 clat (usec): min=0 , max=2915.5K, avg=61685.70, stdev=120598.39 clat (usec): min=0 , max=1933.4K, avg=76935.12, stdev=96603.45 cpu : usr=74.08%, sys=703.84%, ctx=29661403, majf=21354, minf=22460954 cpu : usr=70.92%, sys=702.81%, ctx=77219828, majf=13980, minf=27713137 cpu : usr=72.23%, sys=695.37%, ctx=88081059, majf=18475, minf=28177648 cpu : usr=69.69%, sys=654.13%, ctx=145476035, majf=15867, minf=26176375 With request-based IO path: seq-read : io=2048.0MB, bw=91074KB/s, iops=182147 , runt= 23027msec seq-write : io=2048.0MB, bw=80725KB/s, iops=161449 , runt= 25979msec rand-read : io=3095.7MB, bw=92106KB/s, iops=184211 , runt= 34416msec rand-write: io=3095.7MB, bw=82815KB/s, iops=165630 , runt= 38277msec clat (usec): min=0 , max=1932.4K, avg=77824.17, stdev=170339.49 clat (usec): min=0 , max=2510.2K, avg=78023.96, stdev=146949.15 clat (usec): min=0 , max=3037.2K, avg=74746.53, stdev=128498.27 clat (usec): min=0 , max=1363.4K, avg=89830.75, stdev=114279.68 cpu : usr=53.28%, sys=724.19%, ctx=37988895, majf=17531, minf=23577622 cpu : usr=49.03%, sys=633.20%, ctx=205935380, majf=18197, minf=27288959 cpu : usr=55.78%, sys=722.40%, ctx=101525058, majf=19273, minf=28067082 cpu : usr=56.55%, sys=690.83%, ctx=228205022, majf=18039, minf=26551985 2) Fio test is performed in a 8 vcpu guest with Fusion-IO based guest using kvm tool. Short version: With bio-based IO path, sequential read/write, random read/write IOPS boost : 11%, 11%, 13%, 10% Latency improvement: 10%, 10%, 12%, 10% Long Version: With bio-based IO path: read : io=2048.0MB, bw=58920KB/s, iops=117840 , runt= 35593msec write: io=2048.0MB, bw=64308KB/s, iops=128616 , runt= 32611msec read : io=3095.7MB, bw=59633KB/s, iops=119266 , runt= 53157msec write: io=3095.7MB, bw=62993KB/s, iops=125985 , runt= 50322msec clat (usec): min=0 , max=1284.3K, avg=128109.01, stdev=71513.29 clat (usec): min=94 , max=962339 , avg=116832.95, stdev=65836.80 clat (usec): min=0 , max=1846.6K, avg=128509.99, stdev=89575.07 clat (usec): min=0 , max=2256.4K, avg=121361.84, stdev=82747.25 cpu : usr=56.79%, sys=421.70%, ctx=147335118, majf=21080, minf=19852517 cpu : usr=61.81%, sys=455.53%, ctx=143269950, majf=16027, minf=24800604 cpu : usr=63.10%, sys=455.38%, ctx=178373538, majf=16958, minf=24822612 cpu : usr=62.04%, sys=453.58%, ctx=226902362, majf=16089, minf=23278105 With request-based IO path: read : io=2048.0MB, bw=52896KB/s, iops=105791 , runt= 39647msec write: io=2048.0MB, bw=57856KB/s, iops=115711 , runt= 36248msec read : io=3095.7MB, bw=52387KB/s, iops=104773 , runt= 60510msec write: io=3095.7MB, bw=57310KB/s, iops=114619 , runt= 55312msec clat (usec): min=0 , max=1532.6K, avg=142085.62, stdev=109196.84 clat (usec): min=0 , max=1487.4K, avg=129110.71, stdev=114973.64 clat (usec): min=0 , max=1388.6K, avg=145049.22, stdev=107232.55 clat (usec): min=0 , max=1465.9K, avg=133585.67, stdev=110322.95 cpu : usr=44.08%, sys=590.71%, ctx=451812322, majf=14841, minf=17648641 cpu : usr=48.73%, sys=610.78%, ctx=418953997, majf=22164, minf=26850689 cpu : usr=45.58%, sys=581.16%, ctx=714079216, majf=21497, minf=22558223 cpu : usr=48.40%, sys=599.65%, ctx=656089423, majf=16393, minf=23824409 How to use: - Add 'virtio_blk.use_bio=1' to kernel cmdline or 'modprobe virtio_blk use_bio=1' to enable ->make_request_fn() based I/O path. Cc: Rusty Russell Cc: "Michael S. Tsirkin" Cc: virtualizat...@lists.linux-foundation.org Cc:
Re: [PATCH v2] resource: make sure requested range is included in the root range
On Thu, Jul 12, 2012 at 10:02 PM, Bjorn Helgaas wrote:
> Why don't you fix this right where the problem occurs, in
> __reserve_region_with_split(), with something like this:
>
> if (end > conflict->start && conflict->start > start)
> __reserve_region_with_split(root, start,
> conflict->start-1, name);
> if (start < conflict->end && conflict->end < end && )
> __reserve_region_with_split(root, conflict->end+1, end, name);
>
I am not sure this will behave properly in the overlapping cases.
Consider start=10, end=150, root->start=100, root->end=200.
In this case only the first condition above will be true (150 > 100 &&
100 > 10) and we will try to reserve [10, 99] - which will return
nicely. But we will not reserve [100, 150].
But more important is the fact that by fixing the issue here we won't
be able to log the error and give a chance to upper layer fixing the
problem.
>> + if (start > root->end || end < root->start) {
>> + abort = 1;
>> + pr_err("unable to fix request, aborting it\n");
>
> This message doesn't contain any useful information (range/root/etc).
>
Good point, I will remove it.
--
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] block: Introduce __blk_segment_map_sg() helper
Split the mapping code in blk_rq_map_sg() to a helper
__blk_segment_map_sg(), so that other mapping function, e.g.
blk_bio_map_sg(), can share the code.
Cc: Jens Axboe
Cc: Tejun Heo
Cc: Shaohua Li
Cc: linux-kernel@vger.kernel.org
Suggested-by: Tejun Heo
Suggested-by: Jens Axboe
Signed-off-by: Asias He
---
block/blk-merge.c | 80 ++---
1 file changed, 45 insertions(+), 35 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 160035f..576b68e 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -110,6 +110,49 @@ static int blk_phys_contig_segment(struct request_queue
*q, struct bio *bio,
return 0;
}
+static void
+__blk_segment_map_sg(struct request_queue *q, struct bio_vec *bvec,
+struct scatterlist *sglist, struct bio_vec **bvprv,
+struct scatterlist **sg, int *nsegs, int *cluster)
+{
+
+ int nbytes = bvec->bv_len;
+
+ if (*bvprv && *cluster) {
+ if ((*sg)->length + nbytes > queue_max_segment_size(q))
+ goto new_segment;
+
+ if (!BIOVEC_PHYS_MERGEABLE(*bvprv, bvec))
+ goto new_segment;
+ if (!BIOVEC_SEG_BOUNDARY(q, *bvprv, bvec))
+ goto new_segment;
+
+ (*sg)->length += nbytes;
+ } else {
+new_segment:
+ if (!*sg)
+ *sg = sglist;
+ else {
+ /*
+* If the driver previously mapped a shorter
+* list, we could see a termination bit
+* prematurely unless it fully inits the sg
+* table on each mapping. We KNOW that there
+* must be more entries here or the driver
+* would be buggy, so force clear the
+* termination bit to avoid doing a full
+* sg_init_table() in drivers for each command.
+*/
+ (*sg)->page_link &= ~0x02;
+ *sg = sg_next(*sg);
+ }
+
+ sg_set_page(*sg, bvec->bv_page, nbytes, bvec->bv_offset);
+ (*nsegs)++;
+ }
+ *bvprv = bvec;
+}
+
/*
* map a request to scatterlist, return number of sg entries setup. Caller
* must make sure sg can hold rq->nr_phys_segments entries
@@ -131,41 +174,8 @@ int blk_rq_map_sg(struct request_queue *q, struct request
*rq,
bvprv = NULL;
sg = NULL;
rq_for_each_segment(bvec, rq, iter) {
- int nbytes = bvec->bv_len;
-
- if (bvprv && cluster) {
- if (sg->length + nbytes > queue_max_segment_size(q))
- goto new_segment;
-
- if (!BIOVEC_PHYS_MERGEABLE(bvprv, bvec))
- goto new_segment;
- if (!BIOVEC_SEG_BOUNDARY(q, bvprv, bvec))
- goto new_segment;
-
- sg->length += nbytes;
- } else {
-new_segment:
- if (!sg)
- sg = sglist;
- else {
- /*
-* If the driver previously mapped a shorter
-* list, we could see a termination bit
-* prematurely unless it fully inits the sg
-* table on each mapping. We KNOW that there
-* must be more entries here or the driver
-* would be buggy, so force clear the
-* termination bit to avoid doing a full
-* sg_init_table() in drivers for each command.
-*/
- sg->page_link &= ~0x02;
- sg = sg_next(sg);
- }
-
- sg_set_page(sg, bvec->bv_page, nbytes, bvec->bv_offset);
- nsegs++;
- }
- bvprv = bvec;
+ __blk_segment_map_sg(q, bvec, sglist, , ,
+, );
} /* segments in rq */
--
1.7.10.4
--
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 2/3] block: Add blk_bio_map_sg() helper
Add a helper to map a bio to a scatterlist, modelled after
blk_rq_map_sg.
This helper is useful for any driver that wants to create
a scatterlist from its ->make_request_fn method.
Changes in v2:
- Use __blk_segment_map_sg to avoid duplicated code
- Add cocbook style function comment
Cc: Jens Axboe
Cc: Tejun Heo
Cc: Shaohua Li
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Christoph Hellwig
Signed-off-by: Minchan Kim
Signed-off-by: Asias He
---
block/blk-merge.c | 37 +
include/linux/blkdev.h |2 ++
2 files changed, 39 insertions(+)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 576b68e..e76279e 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -209,6 +209,43 @@ int blk_rq_map_sg(struct request_queue *q, struct request
*rq,
}
EXPORT_SYMBOL(blk_rq_map_sg);
+/**
+ * blk_bio_map_sg - map a bio to a scatterlist
+ * @q: request_queue in question
+ * @bio: bio being mapped
+ * @sglist: scatterlist being mapped
+ *
+ * Note:
+ *Caller must make sure sg can hold bio->bi_phys_segments entries
+ *
+ * Will return the number of sg entries setup
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist)
+{
+ struct bio_vec *bvec, *bvprv;
+ struct scatterlist *sg;
+ int nsegs, cluster;
+ unsigned long i;
+
+ nsegs = 0;
+ cluster = blk_queue_cluster(q);
+
+ bvprv = NULL;
+ sg = NULL;
+ bio_for_each_segment(bvec, bio, i) {
+ __blk_segment_map_sg(q, bvec, sglist, , ,
+, );
+ } /* segments in bio */
+
+ if (sg)
+ sg_mark_end(sg);
+
+ BUG_ON(bio->bi_phys_segments && nsegs > bio->bi_phys_segments);
+ return nsegs;
+}
+EXPORT_SYMBOL(blk_bio_map_sg);
+
static inline int ll_new_hw_segment(struct request_queue *q,
struct request *req,
struct bio *bio)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 07954b0..87fb56c 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -883,6 +883,8 @@ extern void blk_queue_flush_queueable(struct request_queue
*q, bool queueable);
extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device
*bdev);
extern int blk_rq_map_sg(struct request_queue *, struct request *, struct
scatterlist *);
+extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist);
extern void blk_dump_rq_flags(struct request *, char *);
extern long nr_blockdev_pages(void);
--
1.7.10.4
--
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] dw_dmac: set default alignment
On Fri, Jul 13, 2012 at 11:26 AM, viresh kumar wrote: > It would be nice to keep spear-devel in cc, as this is the second > platform that uses this driver. I used to get the list of recipients via get_maintainer script. Will try to not forget about that address in the future. >> The default values are filled to support at least mem-to-mem tests provided >> by >> dmatest module. It makes sense to choose the 4 bytes (2 least significant >> bits) >> alignment by the default. >> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c >> index 3d061c6..2a19ab6 100644 >> --- a/drivers/dma/dw_dmac.c >> +++ b/drivers/dma/dw_dmac.c >> @@ -1485,6 +1485,12 @@ static int __devinit dw_probe(struct platform_device >> *pdev) >> dw->dma.device_tx_status = dwc_tx_status; >> dw->dma.device_issue_pending = dwc_issue_pending; >> >> + /* Set default alignment */ >> + dw->dma.copy_align = 2; >> + dw->dma.xor_align = 2; >> + dw->dma.pq_align = 2; >> + dw->dma.fill_align = 2; > > To understand it more, what does this mean? We will not support > transfers with unaligned > addresses/length to word size? The dmatest module uses those constants to get source, destination addresses and length of the test data aligned. On the other hand we can't use unaligned address in LLI because of the hardware restriction (2 bits are used for choosing AHB master). -- With Best Regards, Andy Shevchenko -- 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 v4 1/3] acpi : cpu hot-remove returns error when cpu_down() fails
Even if cpu_down() fails, acpi_processor_remove() continues to remove the cpu.
But in this case, it should return error number since some process may run on
the cpu. If the cpu has a running process and the cpu is turned the power off,
the system may not work well.
Reviewed-by: Srivatsa S. Bhat
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/processor_driver.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc6.orig/drivers/acpi/processor_driver.c 2012-07-08
09:23:56.0 +0900
+++ linux-3.5-rc6/drivers/acpi/processor_driver.c 2012-07-13
15:11:06.135541317 +0900
@@ -610,7 +610,7 @@ err_free_pr:
static int acpi_processor_remove(struct acpi_device *device, int type)
{
struct acpi_processor *pr = NULL;
-
+ int ret;
if (!device || !acpi_driver_data(device))
return -EINVAL;
@@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
goto free;
if (type == ACPI_BUS_REMOVAL_EJECT) {
- if (acpi_processor_handle_eject(pr))
- return -EINVAL;
+ ret = acpi_processor_handle_eject(pr);
+ if (ret)
+ return ret;
}
acpi_processor_power_exit(pr, device);
@@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
static int acpi_processor_handle_eject(struct acpi_processor *pr)
{
- if (cpu_online(pr->id))
- cpu_down(pr->id);
+ int ret = 0;
+
+ if (cpu_online(pr->id)) {
+ ret = cpu_down(pr->id);
+ if (ret)
+ return ret;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
- return (0);
+ return ret;
}
#else
static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
--
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 0/7] Add support for Freescale's mc34708 to mc13xxx driver
Hello,
[I added git@vger.k.o to Cc: please strip the recipents accordingly if
you reply.]
On Fri, Jul 13, 2012 at 09:02:56AM +1000, Marc Reilly wrote:
> Hi Uwe,
>
> > This series was tested on a Phytec pcm038 (mc13783 on spi) using
> > traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
> > i2c) using dt boot.
> >
> > Philippe's patches are already in next, they are just included here for
> > those who want to test the patches. The 'mfd/mc13xxx: drop modifying
> > driver's id_table in probe' was already sent out yesterday and is
> > included here because the last patch depends on it.
> >
>
> For all patches (that don't already have it):
> Acked-by: Marc Reilly
Thanks.
> If for some reason you do a V2:
> - In patch 6 moves line "#define MC13XXX_NUMREGS 0x3f" around, is this
> necessary?
It doesn't move it around, that's only how it looks. I removed enum
mc13xxx_id (above MC13XXX_NUMREGS) and added struct mc13xxx_variant
(below MC13XXX_NUMREGS). Git choosed to use the closing brace of enum
mc13xxx_id and struct mc13xxx_variant respectively as context (together
with the following empty line).
(For the new readers, here is how git represented the relevant part:
#include
#include
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
+#define MC13XXX_NUMREGS 0x3f
+
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
};
-#define MC13XXX_NUMREGS 0x3f
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
struct mc13xxx {
struct regmap *regmap;
...
)
The following would be an equivalent and (for humans) easier to review
patch:
#include
#include
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
-};
-
#define MC13XXX_NUMREGS 0x3f
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
+};
+
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
+
struct mc13xxx {
struct regmap *regmap;
...
But as this touches 17 lines compared to only 15 using the way git
choosed to represent patch 6, git used the smaller representation. (I'm
not sure this is the correct reason, but at least it sounds sensible.)
Usually this metric is sane, but here it's not. I don't know if you can
do anything about it? E.g. take the number of +, - and context blocks
into account. Then it would be 5 for the patch above vs. 7 for the
way git did it.
Or weight a context line containing
#define MC13XXX_NUMREGS 0x3f
more than two lines one of which is empty and the other only contains a
}?
> - Patch 4 should come last, ie after "add support for mc34708"
Yeah, but it doesn't break bisectibility, and as the rtc patches go in via a
different tree (in fact akpm already took them) it doesn't matter much.
Best regards and thanks for your feedback
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.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/
[PATCH v4 2/3] acpi : prevent cpu from becoming online
Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().
Why does the patch change _cpu_up() logic?
The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it, there is the following race.
hot-remove cpu | _cpu_up()
-
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus()|
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu()|
call acpi_unmap_lsapic() |
call put_online_cpus()|
| start and continue _cpu_up()
return acpi_processor_remove()|
continue hot-remove the cpu|
So _cpu_up() can continue to itself. And hot-remove cpu can also continue
itself. If the patch changes _cpu_up() logic, the race disappears as below:
hot-remove cpu | _cpu_up()
---
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus()|
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu()|
call acpi_unmap_lsapic() |
cpu's cpu_present is set |
to false by set_cpu_present()|
call put_online_cpus()|
| start _cpu_up()
| check cpu_present() and return -EINVAL
return acpi_processor_remove()|
continue hot-remove the cpu|
Reviewed-by: Srivatsa S. Bhat
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/processor_driver.c | 14 ++
kernel/cpu.c|8 +---
2 files changed, 19 insertions(+), 3 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc6.orig/drivers/acpi/processor_driver.c 2012-07-13
17:31:37.799130100 +0900
+++ linux-3.5-rc6/drivers/acpi/processor_driver.c 2012-07-13
17:39:47.727006338 +0900
@@ -850,8 +850,22 @@ static int acpi_processor_handle_eject(s
return ret;
}
+ get_online_cpus();
+ /*
+* The cpu might become online again at this point. So we check whether
+* the cpu has been onlined or not. If the cpu became online, it means
+* that someone wants to use the cpu. So acpi_processor_handle_eject()
+* returns -EAGAIN.
+*/
+ if (unlikely(cpu_online(pr->id))) {
+ put_online_cpus();
+ pr_warn("Failed to remove CPU %d, ", pr->id);
+ pr_warn("because other task brought the CPU back online\n");
+ return -EAGAIN;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
+ put_online_cpus();
return ret;
}
#else
Index: linux-3.5-rc6/kernel/cpu.c
===
--- linux-3.5-rc6.orig/kernel/cpu.c 2012-07-13 17:31:37.800130087 +0900
+++ linux-3.5-rc6/kernel/cpu.c 2012-07-13 17:31:39.661106874 +0900
@@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
struct task_struct *idle;
- if (cpu_online(cpu) || !cpu_present(cpu))
- return -EINVAL;
-
cpu_hotplug_begin();
+ if (cpu_online(cpu) || !cpu_present(cpu)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
idle = idle_thread_get(cpu);
if (IS_ERR(idle)) {
ret = PTR_ERR(idle);
--
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 v4 3/3] acpi : acpi_bus_trim() stops removing devices when failing to remove the device
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
number. But acpi_bus_remove() cannot return error number correctly.
acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if
device cannot be removed correctly, acpi_bus_trim() ignores and continues to
remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing
devices. Therefore acpi_bus_hot_remove_device() can send "_EJ0" to firmware,
even if the device is running on the system. In this case, the system cannot
work well. So acpi_bus_trim() should check whether device was removed or not
correctly. The patch adds error check into some functions to remove the device.
device_release_driver() can return error value by the patch. But the change
does not impact other caller function excluding acpi_bus_trim(), since all
of them does not check return value of device_releae_driver().
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/scan.c| 15 ---
drivers/base/dd.c | 22 +-
include/linux/device.h |2 +-
3 files changed, 30 insertions(+), 9 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/scan.c
===
--- linux-3.5-rc6.orig/drivers/acpi/scan.c 2012-07-13 15:10:46.136790418
+0900
+++ linux-3.5-rc6/drivers/acpi/scan.c 2012-07-13 15:12:41.364349387 +0900
@@ -425,12 +425,17 @@ static int acpi_device_remove(struct dev
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = acpi_dev->driver;
+ int ret;
if (acpi_drv) {
if (acpi_drv->ops.notify)
acpi_device_remove_notify_handler(acpi_dev);
- if (acpi_drv->ops.remove)
- acpi_drv->ops.remove(acpi_dev, acpi_dev->removal_type);
+ if (acpi_drv->ops.remove) {
+ ret = acpi_drv->ops.remove(acpi_dev,
+ acpi_dev->removal_type);
+ if (ret)
+ return ret;
+ }
}
acpi_dev->driver = NULL;
acpi_dev->driver_data = NULL;
@@ -1208,11 +1213,15 @@ static int acpi_device_set_context(struc
static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
{
+ int ret;
+
if (!dev)
return -EINVAL;
dev->removal_type = ACPI_BUS_REMOVAL_EJECT;
- device_release_driver(>dev);
+ ret = device_release_driver(>dev);
+ if (ret)
+ return ret;
if (!rmdevice)
return 0;
Index: linux-3.5-rc6/drivers/base/dd.c
===
--- linux-3.5-rc6.orig/drivers/base/dd.c2012-07-13 15:10:46.136790418
+0900
+++ linux-3.5-rc6/drivers/base/dd.c 2012-07-13 15:14:13.895193383 +0900
@@ -464,9 +464,10 @@ EXPORT_SYMBOL_GPL(driver_attach);
* __device_release_driver() must be called with @dev lock held.
* When called for a USB interface, @dev->parent lock must be held as well.
*/
-static void __device_release_driver(struct device *dev)
+static int __device_release_driver(struct device *dev)
{
struct device_driver *drv;
+ int ret = 0;
drv = dev->driver;
if (drv) {
@@ -482,9 +483,11 @@ static void __device_release_driver(stru
pm_runtime_put_sync(dev);
if (dev->bus && dev->bus->remove)
- dev->bus->remove(dev);
+ ret = dev->bus->remove(dev);
else if (drv->remove)
- drv->remove(dev);
+ ret = drv->remove(dev);
+ if (ret)
+ goto rollback;
devres_release_all(dev);
dev->driver = NULL;
klist_remove(>p->knode_driver);
@@ -494,6 +497,12 @@ static void __device_release_driver(stru
dev);
}
+
+ return ret;
+
+rollback:
+ driver_sysfs_add(dev);
+ return ret;
}
/**
@@ -503,16 +512,19 @@ static void __device_release_driver(stru
* Manually detach device from driver.
* When called for a USB interface, @dev->parent lock must be held.
*/
-void device_release_driver(struct device *dev)
+int device_release_driver(struct device *dev)
{
+ int ret;
/*
* If anyone calls device_release_driver() recursively from
* within their ->remove callback for the same device, they
* will deadlock right here.
*/
device_lock(dev);
- __device_release_driver(dev);
+ ret = __device_release_driver(dev);
device_unlock(dev);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(device_release_driver);
Index: linux-3.5-rc6/include/linux/device.h
===
--- linux-3.5-rc6.orig/include/linux/device.h
[PATCH RESEND 0/5] Add vhost-blk support
Hi folks, [I am resending to fix the broken thread in the previous one.] This patchset adds vhost-blk support. vhost-blk is a in kernel virito-blk device accelerator. Compared to userspace virtio-blk implementation, vhost-blk gives about 5% to 15% performance improvement. Asias He (5): aio: Export symbols and struct kiocb_batch for in kernel aio usage eventfd: Export symbol eventfd_file_create() vhost: Make vhost a separate module vhost-net: Use VHOST_NET_FEATURES for vhost-net vhost-blk: Add vhost-blk support drivers/vhost/Kconfig | 20 +- drivers/vhost/Makefile |6 +- drivers/vhost/blk.c| 600 drivers/vhost/net.c|4 +- drivers/vhost/test.c |4 +- drivers/vhost/vhost.c | 48 drivers/vhost/vhost.h | 18 +- fs/aio.c | 37 ++- fs/eventfd.c |1 + include/linux/aio.h| 21 ++ include/linux/vhost.h |3 + 11 files changed, 731 insertions(+), 31 deletions(-) create mode 100644 drivers/vhost/blk.c -- 1.7.10.4 -- 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 RESEND 2/5] eventfd: Export symbol eventfd_file_create()
This is useful for people who want to create an eventfd in kernel,
e.g. vhost-blk.
Cc: Alexander Viro
Cc: Jeff Moyer
Cc: Michael S. Tsirkin
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Asias He
---
fs/eventfd.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index d81b9f6..b288963 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -402,6 +402,7 @@ struct file *eventfd_file_create(unsigned int count, int
flags)
return file;
}
+EXPORT_SYMBOL_GPL(eventfd_file_create);
SYSCALL_DEFINE2(eventfd2, unsigned int, count, int, flags)
{
--
1.7.10.4
--
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 RESEND 5/5] vhost-blk: Add vhost-blk support
vhost-blk is a in kernel virito-blk device accelerator.
This patch is based on Liu Yuan's implementation with various
improvements and bug fixes. Notably, this patch makes guest notify and
host completion processing in parallel which gives about 60% performance
improvement compared to Liu Yuan's implementation.
Performance evaluation:
-
The comparison is between kvm tool with usersapce implementation and kvm
tool with vhost-blk.
1) Fio with libaio ioengine on Fusion IO device
With bio-based IO path, sequential read/write, random read/write
IOPS boost : 8.4%, 15.3%, 10.4%, 14.6%
Latency improvement: 8.5%, 15.4%, 10.4%, 15.1%
2) Fio with vsync ioengine on Fusion IO device
With bio-based IO path, sequential read/write, random read/write
IOPS boost : 10.5%, 4.8%, 5.2%, 5.6%
Latency improvement: 11.4%, 5.0%, 5.2%, 5.8%
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Asias He
---
drivers/vhost/Kconfig | 10 +
drivers/vhost/Makefile |2 +
drivers/vhost/blk.c| 600
drivers/vhost/vhost.h |5 +
include/linux/vhost.h |3 +
5 files changed, 620 insertions(+)
create mode 100644 drivers/vhost/blk.c
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index c387067..fa071a8 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -16,4 +16,14 @@ config VHOST_NET
To compile this driver as a module, choose M here: the module will
be called vhost_net.
+config VHOST_BLK
+ tristate "Host kernel accelerator for virtio blk (EXPERIMENTAL)"
+ depends on VHOST && BLOCK && AIO && EVENTFD && EXPERIMENTAL
+ ---help---
+ This kernel module can be loaded in host kernel to accelerate
+ guest block with virtio_blk. Not to be confused with virtio_blk
+ module itself which needs to be loaded in guest kernel.
+
+ To compile this driver as a module, choose M here: the module will
+ be called vhost_blk.
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index cd36885..aa461d5 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -1,4 +1,6 @@
obj-$(CONFIG_VHOST)+= vhost.o
obj-$(CONFIG_VHOST_NET) += vhost_net.o
+obj-$(CONFIG_VHOST_BLK) += vhost_blk.o
vhost_net-y:= net.o
+vhost_blk-y:= blk.o
diff --git a/drivers/vhost/blk.c b/drivers/vhost/blk.c
new file mode 100644
index 000..6a94894
--- /dev/null
+++ b/drivers/vhost/blk.c
@@ -0,0 +1,600 @@
+/*
+ * Copyright (C) 2011 Taobao, Inc.
+ * Author: Liu Yuan
+ *
+ * Copyright (C) 2012 Red Hat, Inc.
+ * Author: Asias He
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ *
+ * virtio-blk server in host kernel.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vhost.h"
+
+#define BLK_HDR0
+
+enum {
+ VHOST_BLK_VQ_REQ = 0,
+ VHOST_BLK_VQ_MAX = 1,
+};
+
+struct vhost_blk_req {
+ u16 head;
+ u8 *status;
+};
+
+struct vhost_blk {
+ struct task_struct *worker_host_kick;
+ struct task_struct *worker;
+ struct vhost_blk_req *reqs;
+ struct vhost_virtqueue vq;
+ struct eventfd_ctx *ectx;
+ struct io_event *ioevent;
+ struct kioctx *ioctx;
+ struct vhost_dev dev;
+ struct file *efile;
+ u64 ioevent_nr;
+ bool stop;
+};
+
+static inline int vhost_blk_read_events(struct vhost_blk *blk, long nr)
+{
+ mm_segment_t old_fs = get_fs();
+ int ret;
+
+ set_fs(KERNEL_DS);
+ ret = read_events(blk->ioctx, nr, nr, blk->ioevent, NULL);
+ set_fs(old_fs);
+
+ return ret;
+}
+
+static int vhost_blk_setup(struct vhost_blk *blk)
+{
+ struct kioctx *ctx;
+
+ if (blk->ioctx)
+ return 0;
+
+ blk->ioevent_nr = blk->vq.num;
+ ctx = ioctx_alloc(blk->ioevent_nr);
+ if (IS_ERR(ctx)) {
+ pr_err("Failed to ioctx_alloc");
+ return PTR_ERR(ctx);
+ }
+ put_ioctx(ctx);
+ blk->ioctx = ctx;
+
+ blk->ioevent = kmalloc(sizeof(struct io_event) * blk->ioevent_nr,
+ GFP_KERNEL);
+ if (!blk->ioevent) {
+ pr_err("Failed to allocate memory for io_events");
+ return -ENOMEM;
+ }
+
+ blk->reqs = kmalloc(sizeof(struct vhost_blk_req) * blk->ioevent_nr,
+ GFP_KERNEL);
+ if (!blk->reqs) {
+ pr_err("Failed to allocate memory for vhost_blk_req");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static inline int vhost_blk_set_status(struct vhost_blk *blk, u8 *statusp,
+ u8 status)
+{
+ if (copy_to_user(statusp, , sizeof(status))) {
+ vq_err(>vq, "Failed to
[PATCH RESEND 1/5] aio: Export symbols and struct kiocb_batch for in kernel aio usage
This is useful for people who want to use aio in kernel, e.g. vhost-blk.
Cc: Benjamin LaHaise
Cc: Alexander Viro
Cc: Jeff Moyer
Cc: James Bottomley
Cc: Michael S. Tsirkin
Cc: linux-...@kvack.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Asias He
---
fs/aio.c| 37 ++---
include/linux/aio.h | 21 +
2 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 55c4c76..93dfbdd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -224,22 +224,24 @@ static void __put_ioctx(struct kioctx *ctx)
call_rcu(>rcu_head, ctx_rcu_free);
}
-static inline int try_get_ioctx(struct kioctx *kioctx)
+inline int try_get_ioctx(struct kioctx *kioctx)
{
return atomic_inc_not_zero(>users);
}
+EXPORT_SYMBOL(try_get_ioctx);
-static inline void put_ioctx(struct kioctx *kioctx)
+inline void put_ioctx(struct kioctx *kioctx)
{
BUG_ON(atomic_read(>users) <= 0);
if (unlikely(atomic_dec_and_test(>users)))
__put_ioctx(kioctx);
}
+EXPORT_SYMBOL(put_ioctx);
/* ioctx_alloc
* Allocates and initializes an ioctx. Returns an ERR_PTR if it failed.
*/
-static struct kioctx *ioctx_alloc(unsigned nr_events)
+struct kioctx *ioctx_alloc(unsigned nr_events)
{
struct mm_struct *mm;
struct kioctx *ctx;
@@ -303,6 +305,7 @@ out_freectx:
dprintk("aio: error allocating ioctx %d\n", err);
return ERR_PTR(err);
}
+EXPORT_SYMBOL(ioctx_alloc);
/* kill_ctx
* Cancels all outstanding aio requests on an aio context. Used
@@ -436,23 +439,14 @@ static struct kiocb *__aio_get_req(struct kioctx *ctx)
return req;
}
-/*
- * struct kiocb's are allocated in batches to reduce the number of
- * times the ctx lock is acquired and released.
- */
-#define KIOCB_BATCH_SIZE 32L
-struct kiocb_batch {
- struct list_head head;
- long count; /* number of requests left to allocate */
-};
-
-static void kiocb_batch_init(struct kiocb_batch *batch, long total)
+void kiocb_batch_init(struct kiocb_batch *batch, long total)
{
INIT_LIST_HEAD(>head);
batch->count = total;
}
+EXPORT_SYMBOL(kiocb_batch_init);
-static void kiocb_batch_free(struct kioctx *ctx, struct kiocb_batch *batch)
+void kiocb_batch_free(struct kioctx *ctx, struct kiocb_batch *batch)
{
struct kiocb *req, *n;
@@ -470,6 +464,7 @@ static void kiocb_batch_free(struct kioctx *ctx, struct
kiocb_batch *batch)
wake_up_all(>wait);
spin_unlock_irq(>ctx_lock);
}
+EXPORT_SYMBOL(kiocb_batch_free);
/*
* Allocate a batch of kiocbs. This avoids taking and dropping the
@@ -540,7 +535,7 @@ out:
return allocated;
}
-static inline struct kiocb *aio_get_req(struct kioctx *ctx,
+inline struct kiocb *aio_get_req(struct kioctx *ctx,
struct kiocb_batch *batch)
{
struct kiocb *req;
@@ -552,6 +547,7 @@ static inline struct kiocb *aio_get_req(struct kioctx *ctx,
list_del(>ki_batch);
return req;
}
+EXPORT_SYMBOL(aio_get_req);
static inline void really_put_req(struct kioctx *ctx, struct kiocb *req)
{
@@ -721,7 +717,7 @@ static inline int __queue_kicked_iocb(struct kiocb *iocb)
* simplifies the coding of individual aio operations as
* it avoids various potential races.
*/
-static ssize_t aio_run_iocb(struct kiocb *iocb)
+ssize_t aio_run_iocb(struct kiocb *iocb)
{
struct kioctx *ctx = iocb->ki_ctx;
ssize_t (*retry)(struct kiocb *);
@@ -815,6 +811,7 @@ out:
}
return ret;
}
+EXPORT_SYMBOL(aio_run_iocb);
/*
* __aio_run_iocbs:
@@ -1136,7 +1133,7 @@ static inline void clear_timeout(struct aio_timeout *to)
del_singleshot_timer_sync(>timer);
}
-static int read_events(struct kioctx *ctx,
+int read_events(struct kioctx *ctx,
long min_nr, long nr,
struct io_event __user *event,
struct timespec __user *timeout)
@@ -1252,6 +1249,7 @@ out:
destroy_timer_on_stack();
return i ? i : ret;
}
+EXPORT_SYMBOL(read_events);
/* Take an ioctx and remove it from the list of ioctx's. Protects
* against races with itself via ->dead.
@@ -1492,7 +1490,7 @@ static ssize_t aio_setup_single_vector(int type, struct
file * file, struct kioc
* Performs the initial checks and aio retry method
* setup for the kiocb at the time of io submission.
*/
-static ssize_t aio_setup_iocb(struct kiocb *kiocb, bool compat)
+ssize_t aio_setup_iocb(struct kiocb *kiocb, bool compat)
{
struct file *file = kiocb->ki_filp;
ssize_t ret = 0;
@@ -1570,6 +1568,7 @@ static ssize_t aio_setup_iocb(struct kiocb *kiocb, bool
compat)
return 0;
}
+EXPORT_SYMBOL(aio_setup_iocb);
static int io_submit_one(struct kioctx *ctx, struct iocb __user
[PATCH RESEND 4/5] vhost-net: Use VHOST_NET_FEATURES for vhost-net
vhost-net's feature does not deseve the name VHOST_FEATURES. Use
VHOST_NET_FEATURES instead.
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Asias He
---
drivers/vhost/net.c |4 ++--
drivers/vhost/test.c |4 ++--
drivers/vhost/vhost.h | 12 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index f82a739..072cbba 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -823,14 +823,14 @@ static long vhost_net_ioctl(struct file *f, unsigned int
ioctl,
return -EFAULT;
return vhost_net_set_backend(n, backend.index, backend.fd);
case VHOST_GET_FEATURES:
- features = VHOST_FEATURES;
+ features = VHOST_NET_FEATURES;
if (copy_to_user(featurep, , sizeof features))
return -EFAULT;
return 0;
case VHOST_SET_FEATURES:
if (copy_from_user(, featurep, sizeof features))
return -EFAULT;
- if (features & ~VHOST_FEATURES)
+ if (features & ~VHOST_NET_FEATURES)
return -EOPNOTSUPP;
return vhost_net_set_features(n, features);
case VHOST_RESET_OWNER:
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 3de00d9..91d6f06 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -261,14 +261,14 @@ static long vhost_test_ioctl(struct file *f, unsigned int
ioctl,
return -EFAULT;
return vhost_test_run(n, test);
case VHOST_GET_FEATURES:
- features = VHOST_FEATURES;
+ features = VHOST_NET_FEATURES;
if (copy_to_user(featurep, , sizeof features))
return -EFAULT;
return 0;
case VHOST_SET_FEATURES:
if (copy_from_user(, featurep, sizeof features))
return -EFAULT;
- if (features & ~VHOST_FEATURES)
+ if (features & ~VHOST_NET_FEATURES)
return -EOPNOTSUPP;
return vhost_test_set_features(n, features);
case VHOST_RESET_OWNER:
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index c5c7fb0..cc046a9 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -199,12 +199,12 @@ int vhost_zerocopy_signal_used(struct vhost_virtqueue
*vq);
} while (0)
enum {
- VHOST_FEATURES = (1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) |
-(1ULL << VIRTIO_RING_F_INDIRECT_DESC) |
-(1ULL << VIRTIO_RING_F_EVENT_IDX) |
-(1ULL << VHOST_F_LOG_ALL) |
-(1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
-(1ULL << VIRTIO_NET_F_MRG_RXBUF),
+ VHOST_NET_FEATURES =(1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) |
+ (1ULL << VIRTIO_RING_F_INDIRECT_DESC) |
+ (1ULL << VIRTIO_RING_F_EVENT_IDX) |
+ (1ULL << VHOST_F_LOG_ALL) |
+ (1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
+ (1ULL << VIRTIO_NET_F_MRG_RXBUF),
};
static inline int vhost_has_feature(struct vhost_dev *dev, int bit)
--
1.7.10.4
--
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] dw_dmac: set default alignment
On 13/07/12 09:45, Andy Shevchenko wrote: >> > To understand it more, what does this mean? We will not support >> > transfers with unaligned >> > addresses/length to word size? > The dmatest module uses those constants to get source, destination > addresses and length of the test data aligned. On the other hand we > can't use unaligned address in LLI because of the hardware restriction > (2 bits are used for choosing AHB master). To be clear, we can't use unaligned address of an LLI struct, but src/dest address inside LLI can be unaligned. I wanted to ask, will normal memcpy for anybody will work with unaligned addresses with this patch? I believe they will. -- Viresh -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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 RESEND 3/5] vhost: Make vhost a separate module
Currently, vhost-net is the only consumer of vhost infrastructure. So
vhost infrastructure and vhost-net driver are in a single module.
Separating this as a vhost.ko module and a vhost-net.ko module makes it
is easier to share code with other vhost drivers, e.g. vhost-blk.ko,
tcm-vhost.ko.
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Asias He
---
drivers/vhost/Kconfig | 10 +-
drivers/vhost/Makefile |4 +++-
drivers/vhost/vhost.c | 48
drivers/vhost/vhost.h |1 +
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index e4e2fd1..c387067 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -1,6 +1,14 @@
+config VHOST
+ tristate "Host kernel accelerator for virtio (EXPERIMENTAL)"
+ ---help---
+ This kernel module can be loaded in host kernel to accelerate
+ guest networking and block.
+
+ To compile this driver as a module, choose M here: the module will
+ be called vhost_net.
config VHOST_NET
tristate "Host kernel accelerator for virtio net (EXPERIMENTAL)"
- depends on NET && EVENTFD && (TUN || !TUN) && (MACVTAP || !MACVTAP) &&
EXPERIMENTAL
+ depends on VHOST && NET && EVENTFD && (TUN || !TUN) && (MACVTAP ||
!MACVTAP) && EXPERIMENTAL
---help---
This kernel module can be loaded in host kernel to accelerate
guest networking with virtio_net. Not to be confused with virtio_net
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 72dd020..cd36885 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -1,2 +1,4 @@
+obj-$(CONFIG_VHOST)+= vhost.o
obj-$(CONFIG_VHOST_NET) += vhost_net.o
-vhost_net-y := vhost.o net.o
+
+vhost_net-y:= net.o
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 112156f..6e9f586 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -84,6 +85,7 @@ void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t
fn,
vhost_work_init(>work, fn);
}
+EXPORT_SYMBOL_GPL(vhost_poll_init);
/* Start polling a file. We add ourselves to file's wait queue. The caller must
* keep a reference to a file until after vhost_poll_stop is called. */
@@ -95,6 +97,7 @@ void vhost_poll_start(struct vhost_poll *poll, struct file
*file)
if (mask)
vhost_poll_wakeup(>wait, 0, 0, (void *)mask);
}
+EXPORT_SYMBOL_GPL(vhost_poll_start);
/* Stop polling a file. After this function returns, it becomes safe to drop
the
* file reference. You must also flush afterwards. */
@@ -102,6 +105,7 @@ void vhost_poll_stop(struct vhost_poll *poll)
{
remove_wait_queue(poll->wqh, >wait);
}
+EXPORT_SYMBOL_GPL(vhost_poll_stop);
static bool vhost_work_seq_done(struct vhost_dev *dev, struct vhost_work *work,
unsigned seq)
@@ -136,6 +140,7 @@ void vhost_poll_flush(struct vhost_poll *poll)
{
vhost_work_flush(poll->dev, >work);
}
+EXPORT_SYMBOL_GPL(vhost_poll_flush);
static inline void vhost_work_queue(struct vhost_dev *dev,
struct vhost_work *work)
@@ -155,6 +160,7 @@ void vhost_poll_queue(struct vhost_poll *poll)
{
vhost_work_queue(poll->dev, >work);
}
+EXPORT_SYMBOL_GPL(vhost_poll_queue);
static void vhost_vq_reset(struct vhost_dev *dev,
struct vhost_virtqueue *vq)
@@ -251,6 +257,7 @@ void vhost_enable_zcopy(int vq)
{
vhost_zcopy_mask |= 0x1 << vq;
}
+EXPORT_SYMBOL_GPL(vhost_enable_zcopy);
/* Helper to allocate iovec buffers for all vqs. */
static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
@@ -322,6 +329,7 @@ long vhost_dev_init(struct vhost_dev *dev,
return 0;
}
+EXPORT_SYMBOL_GPL(vhost_dev_init);
/* Caller should have device mutex */
long vhost_dev_check_owner(struct vhost_dev *dev)
@@ -329,6 +337,7 @@ long vhost_dev_check_owner(struct vhost_dev *dev)
/* Are you the owner? If not, I don't think you mean to do that */
return dev->mm == current->mm ? 0 : -EPERM;
}
+EXPORT_SYMBOL_GPL(vhost_dev_check_owner);
struct vhost_attach_cgroups_struct {
struct vhost_work work;
@@ -414,6 +423,7 @@ long vhost_dev_reset_owner(struct vhost_dev *dev)
RCU_INIT_POINTER(dev->memory, memory);
return 0;
}
+EXPORT_SYMBOL_GPL(vhost_dev_reset_owner);
/* In case of DMA done not in order in lower device driver for some reason.
* upend_idx is used to track end of used idx, done_idx is used to track head
@@ -438,6 +448,7 @@ int vhost_zerocopy_signal_used(struct vhost_virtqueue *vq)
vq->done_idx = i;
return j;
}
+EXPORT_SYMBOL_GPL(vhost_zerocopy_signal_used);
/* Caller should have device mutex
Re: [linux-pm] [RESEND PATCH v4 1/5] thermal: add generic cpufreq cooling implementation
On Thu, Jul 12, 2012 at 8:40 PM, Valentin, Eduardo wrote: > Amit, > > On Thu, Jul 12, 2012 at 4:41 PM, Amit Daniel Kachhap > wrote: >> This patchset introduces a new generic cooling device based on cpufreq >> that can be used on non-ACPI platforms. As a proof of concept, we have >> drivers for the following platforms using this mechanism now: >> >> * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. >> * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git >> omap4460_thermal) > > FYI, I have rewriten the OMAP BG driver and currently trying to push > it to staging area. It should now support more omap versions. I will > readapt the cpu cooling based on this patch. > > I am keeping the reworked driver here: > g...@gitorious.org:thermal-framework/thermal-framework.git > thermal_work/omap/bandgap_staging > Yes Eduardo, The link I have given here is slightly old. After your implementation is done maybe this link can be updated. Thanks, Amit D >> * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git >> imx6q_thermal) >> >> There is a small change in cpufreq cooling registration APIs, so a minor >> change is needed for OMAP and Freescale platforms. >> >> Brief Description: >> >> 1) The generic cooling devices code is placed inside driver/thermal/* >>as placing inside acpi folder will need un-necessary enabling of acpi >>code. This codes is architecture independent. >> >> 2) This patchset adds generic cpu cooling low level implementation >>through frequency clipping. In future, other cpu related cooling >>devices may be added here. An ACPI version of this already exists >>(drivers/acpi/processor_thermal.c) . But this will be useful for >>platforms like ARM using the generic thermal interface along with the >>generic cpu cooling devices. The cooling device registration API's >>return cooling device pointers which can be easily binded with the >>thermal zone trip points. The important APIs exposed are, >> >>a) struct thermal_cooling_device *cpufreq_cooling_register( >> struct freq_clip_table *tab_ptr, unsigned int tab_size) >>b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) >> >> 3) Samsung exynos platform thermal implementation is done using the >>generic cpu cooling APIs and the new trip type. The temperature sensor >>driver present in the hwmon folder(registered as hwmon driver) is moved >>to thermal folder and registered as a thermal driver. >> >> A simple data/control flow diagrams is shown below, >> >> Core Linux thermal <-> Exynos thermal interface <- Temperature >> Sensor >> | | >> \|/| >> Cpufreq cooling device <--- >> >> TODO: >> *Will send the DT enablement patches later after the driver is merged. >> >> This patch: >> >> Add support for generic cpu thermal cooling low level implementations >> using frequency scaling up/down based on the registration parameters. >> Different cpu related cooling devices can be registered by the user and >> the binding of these cooling devices to the corresponding trip points can >> be easily done as the registration APIs return the cooling device pointer. >> The user of these APIs are responsible for passing clipping frequency . >> The drivers can also register to recieve notification about any cooling >> action called. >> >> [a...@linux-foundation.org: fix comment layout] >> Signed-off-by: Amit Daniel Kachhap >> Cc: Donggeun Kim >> Cc: Guenter Roeck >> Cc: SangWook Ju >> Cc: Durgadoss >> Cc: Len Brown >> Cc: Jean Delvare >> Signed-off-by: Andrew Morton >> --- >> Documentation/thermal/cpu-cooling-api.txt | 60 >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile |3 +- >> drivers/thermal/cpu_cooling.c | 483 >> + >> include/linux/cpu_cooling.h | 99 ++ >> 5 files changed, 655 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..557adb8 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,60 @@ >> +CPU cooling APIs How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 12 May 2012 >> + >> +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug etc) provides >> +registration/unregistration APIs to the caller. The binding of the cooling >> +devices to the trip point is left for the user. The registration APIs >> returns >> +the cooling device
Re: [RFC PATCH v3 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
At 07/09/2012 06:26 PM, Yasuaki Ishimatsu Wrote:
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
>
> Note : The code does not free firmware_map_entry since there is no way to free
>memory which is allocated by bootmem.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/firmware/memmap.c| 78
> ++-
> include/linux/firmware-map.h |6 +++
> mm/memory_hotplug.c |6 ++-
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> Index: linux-3.5-rc6/mm/memory_hotplug.c
> ===
> --- linux-3.5-rc6.orig/mm/memory_hotplug.c2012-07-09 18:23:13.323844923
> +0900
> +++ linux-3.5-rc6/mm/memory_hotplug.c 2012-07-09 18:23:19.522767424 +0900
> @@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
>
> int remove_memory(int nid, u64 start, u64 size)
> {
> - return -EBUSY;
> + lock_memory_hotplug();
> + /* remove memmap entry */
> + firmware_map_remove(start, start + size - 1, "System RAM");
firmware_map_remove() is in meminit section, so remove_memory() should be in
ref section.
Thanks
Wen Congyang
> + unlock_memory_hotplug();
> + return 0;
>
> }
> EXPORT_SYMBOL_GPL(remove_memory);
> Index: linux-3.5-rc6/include/linux/firmware-map.h
> ===
> --- linux-3.5-rc6.orig/include/linux/firmware-map.h 2012-07-09
> 18:23:09.532892314 +0900
> +++ linux-3.5-rc6/include/linux/firmware-map.h2012-07-09
> 18:23:19.523767412 +0900
> @@ -25,6 +25,7 @@
>
> int firmware_map_add_early(u64 start, u64 end, const char *type);
> int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
> +int firmware_map_remove(u64 start, u64 end, const char *type);
>
> #else /* CONFIG_FIRMWARE_MEMMAP */
>
> @@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
> return 0;
> }
>
> +static inline int firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> + return 0;
> +}
> +
> #endif /* CONFIG_FIRMWARE_MEMMAP */
>
> #endif /* _LINUX_FIRMWARE_MAP_H */
> Index: linux-3.5-rc6/drivers/firmware/memmap.c
> ===
> --- linux-3.5-rc6.orig/drivers/firmware/memmap.c 2012-07-09
> 18:23:09.532892314 +0900
> +++ linux-3.5-rc6/drivers/firmware/memmap.c 2012-07-09 18:25:46.371931554
> +0900
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Data types
> --
> @@ -79,7 +80,22 @@ static const struct sysfs_ops memmap_att
> .show = memmap_attr_show,
> };
>
> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry,
> kobj)
> +
> +static void release_firmware_map_entry(struct kobject *kobj)
> +{
> + struct firmware_map_entry *entry = to_memmap_entry(kobj);
> + struct page *head_page;
> +
> + head_page = virt_to_head_page(entry);
> + if (PageSlab(head_page))
> + kfree(entry);
> +
> + /* There is no way to free memory allocated from bootmem*/
> +}
> +
> static struct kobj_type memmap_ktype = {
> + .release= release_firmware_map_entry,
> .sysfs_ops = _attr_ops,
> .default_attrs = def_attrs,
> };
> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 st
> return 0;
> }
>
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry
> *entry)
> +{
> + list_del(>list);
> +}
> +
> /*
> * Add memmap entry on sysfs
> */
> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct
> return 0;
> }
>
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry
> *entry)
> +{
> + kobject_put(>kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)
> +{
> + struct firmware_map_entry *entry;
> +
> + list_for_each_entry(entry, _entries, list)
> + if ((entry->start == start) && (entry->end == end) &&
> + (!strcmp(entry->type, type)))
> + return entry;
> +
> + return NULL;
> +}
> +
> /**
> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
> * memory hotplug.
> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 st
> return
Re: ARM: why smp_mb() is not needed in the "__mutex_fastpath_lock" and "__mutex_fastpath_unlock" functions
For example, in the following scenario, Process2 may get the wrong value; Process1: mutex_lock(); write data; (store operation) mutex_unlock(); Process2: mutex_lock(); read data; (load operation) mutex_unlock(); Suppose Process1 gets the lock first, write data and unlock. If the store operation completes very slowly, the load operation of the Process2 will fail to get the new value. Since there are no dmb instructions in the mutex_lock and mutex_unlock, which doesn't make sure that after Process2 gets the lock, the result of the Process1's store operation will be seen by the Process2. 2012/7/13 Li Haifeng : > Hi Shan, > > 2012/7/12 shan kang : >> Hello, >>I wonder why smp_mb() is not needed in the "__mutex_fastpath_lock" >> and "__mutex_fastpath_unlock" functions which are located in the >> "arch/arm/include/asm/mutex.h"? >>I think "dmb" instruction is necessary there. > > Why necessary? Could you explain more detailed? > >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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/6] mmc: dw_mmc: lookup for optional biu and ciu clocks
On 12 July 2012 18:24, Thomas Abraham wrote:
> Some platforms allow for clock gating and control of bus interface unit clock
> and card interface unit clock. Add support for clock lookup of optional biu
> and ciu clocks for clock gating and clock speed determination.
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Thomas Abraham
> ---
> drivers/mmc/host/dw_mmc.c | 42 +++---
> include/linux/mmc/dw_mmc.h |4
> 2 files changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index cd58063..679473c 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1953,18 +1953,38 @@ int dw_mci_probe(struct dw_mci *host)
> return -ENODEV;
> }
>
> - if (!host->pdata->bus_hz) {
> + host->biu_clk = clk_get(host->dev, "biu");
> + if (IS_ERR(host->biu_clk))
> + dev_dbg(host->dev, "biu clock not available\n");
> + else
> + clk_prepare_enable(host->biu_clk);
> +
> + host->ciu_clk = clk_get(host->dev, "ciu");
> + if (IS_ERR(host->ciu_clk))
> + dev_dbg(host->dev, "ciu clock not available\n");
> + else
> + clk_prepare_enable(host->ciu_clk);
> +
> + if (IS_ERR(host->ciu_clk))
> + host->bus_hz = host->pdata->bus_hz;
> + else
> + host->bus_hz = clk_get_rate(host->ciu_clk);
> +
> + if (!host->bus_hz) {
> dev_err(host->dev,
> "Platform data must supply bus speed\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err_clk;
> }
>
> - host->bus_hz = host->pdata->bus_hz;
> host->quirks = host->pdata->quirks;
>
> spin_lock_init(>lock);
> INIT_LIST_HEAD(>queue);
>
> + host->dma_ops = host->pdata->dma_ops;
> + dw_mci_init_dma(host);
This initialization is already done.
> +
> /*
> * Get the host data width - this assumes that HCON has been set with
> * the correct values.
> @@ -2109,6 +2129,16 @@ err_dmaunmap:
> regulator_disable(host->vmmc);
> regulator_put(host->vmmc);
> }
> +
> +err_clk:
> + if (!IS_ERR(host->ciu_clk)) {
> + clk_disable_unprepare(host->ciu_clk);
> + clk_put(host->ciu_clk);
> + }
> + if (!IS_ERR(host->biu_clk)) {
> + clk_disable_unprepare(host->biu_clk);
> + clk_put(host->biu_clk);
> + }
> return ret;
> }
> EXPORT_SYMBOL(dw_mci_probe);
> @@ -2142,6 +2172,12 @@ void dw_mci_remove(struct dw_mci *host)
> regulator_put(host->vmmc);
> }
>
> + if (!IS_ERR(host->ciu_clk))
> + clk_disable_unprepare(host->ciu_clk);
> + if (!IS_ERR(host->biu_clk))
> + clk_disable_unprepare(host->biu_clk);
> + clk_put(host->ciu_clk);
> + clk_put(host->biu_clk);
> }
> EXPORT_SYMBOL(dw_mci_remove);
>
> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
> index a37a573..787ad56 100644
> --- a/include/linux/mmc/dw_mmc.h
> +++ b/include/linux/mmc/dw_mmc.h
> @@ -78,6 +78,8 @@ struct mmc_data;
> * @data_offset: Set the offset of DATA register according to VERID.
> * @dev: Device associated with the MMC controller.
> * @pdata: Platform data associated with the MMC controller.
> + * @biu_clk: Pointer to bus interface unit clock instance.
> + * @ciu_clk: Pointer to card interface unit clock instance.
> * @slot: Slots sharing this MMC controller.
> * @fifo_depth: depth of FIFO.
> * @data_shift: log2 of FIFO item size.
> @@ -158,6 +160,8 @@ struct dw_mci {
> u16 data_offset;
> struct device *dev;
> struct dw_mci_board *pdata;
> + struct clk *biu_clk;
> + struct clk *ciu_clk;
> struct dw_mci_slot *slot[MAX_MCI_SLOTS];
>
> /* FIFO push and pull */
> --
> 1.6.6.rc2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: rcu_dyntick and suspicious RCU usage
On Thu, Jul 12, 2012 at 10:02:42AM -0700, Paul E. McKenney wrote: > On Fri, Jul 13, 2012 at 12:57:38AM +0800, Fengguang Wu wrote: > > On Thu, Jul 12, 2012 at 09:43:08AM -0700, Paul E. McKenney wrote: > > > On Wed, Jul 11, 2012 at 12:49:24AM -0700, Paul E. McKenney wrote: > > > > On Tue, Jul 10, 2012 at 12:47:00PM +0800, Fengguang Wu wrote: > > > > > Hi Paul, > > > > > > > > > > Fortunately this bug is bisectable and the first bad commit is: > > > > > > > > > > commit 9b2e4f1880b789be1f24f9684f7a54b90310b5c0 > > > > > Author: Paul E. McKenney > > > > > Date: Fri Sep 30 12:10:22 2011 -0700 > > > > > > > > > > rcu: Track idleness independent of idle tasks > > > > > > > > OK, there is a problem in TINY_RCU's handling of dyntick-idle: it > > > > traces while in idle. The confusion on my part was that in TREE_RCU, > > > > the nesting and dyntick-idle indication are different, while in > > > > TINY_RCU they are one and the same. > > > > > > > > Does the following patch help? > > > > > > This one failed in my testing. Please see the end for the fixed > > > version, with on small but important change. > > > > It worked, thanks! > > > > Tested-by: Fengguang Wu > > Very good! (And please ignore my resend of the same patch.) > > I will queue this. Will you recommend it for -stable? It impacts 3.3/3.4. I tested it on 3.4 and it works fine. However for 3.3, the patch cannot apply cleanly. Thanks, Fengguang -- 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 0/1] leds: Add LED driver for lm3554 chip
From: "G.Shark Jeong" LM3554 : The LM3554 is a 2 MHz fixed-frequency synchronous boost converter with 1.2A dual high side led drivers. Datasheet: www.ti.com G.Shark Jeong (1): leds: Add LED driver for lm3554 chip drivers/leds/Kconfig |8 + drivers/leds/Makefile |1 + drivers/leds/leds-lm3554.c| 324 + include/linux/platform_data/leds-lm3554.h | 66 ++ 4 files changed, 399 insertions(+), 0 deletions(-) create mode 100644 drivers/leds/leds-lm3554.c create mode 100644 include/linux/platform_data/leds-lm3554.h -- 1.7.5.4 -- 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] leds: Add LED driver for lm3554 chip
From: "G.Shark Jeong"
LM3554 :
The LM3554 is a 2 MHz fixed-frequency synchronous boost
converter with 1.2A dual high side led drivers.
Datasheet: www.ti.com
Signed-off-by: G.Shark Jeong
---
drivers/leds/Kconfig |8 +
drivers/leds/Makefile |1 +
drivers/leds/leds-lm3554.c| 324 +
include/linux/platform_data/leds-lm3554.h | 66 ++
4 files changed, 399 insertions(+), 0 deletions(-)
create mode 100644 drivers/leds/leds-lm3554.c
create mode 100644 include/linux/platform_data/leds-lm3554.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 12b2b55..ad54bc2 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -415,6 +415,14 @@ config LEDS_MAX8997
This option enables support for on-chip LED drivers on
MAXIM MAX8997 PMIC.
+config LEDS_LM3554
+ tristate "LED support for LM3554"
+ depends on LEDS_CLASS && I2C
+ select REGMAP_I2C
+ help
+ This option enables support for LEDs connected to LM3554.
+ LM3554 includes Torch, Flash and Indicator functions.
+
config LEDS_OT200
tristate "LED support for the Bachmann OT200"
depends on LEDS_CLASS && HAS_IOMEM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index f8958cd..19903ed 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_LEDS_NETXBIG)+= leds-netxbig.o
obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
obj-$(CONFIG_LEDS_RENESAS_TPU) += leds-renesas-tpu.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
+obj-$(CONFIG_LEDS_LM3554) += leds-lm3554.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3554.c b/drivers/leds/leds-lm3554.c
new file mode 100644
index 000..4f53086
--- /dev/null
+++ b/drivers/leds/leds-lm3554.c
@@ -0,0 +1,324 @@
+/*
+* Simple driver for Texas Instruments LM3554 LED Flash driver chip
+* Copyright (C) 2012 Texas Instruments
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+*/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_TORCH (0xA0)
+#define REG_FLASH (0xB0)
+#define REG_FLASH_TIME (0xC0)
+#define REG_FLAG (0xD0)
+#define REG_CONF1 (0xE0)
+#define REG_CONF2 (0xF0)
+#define REG_GPIO (0x20)
+#define REG_VIN_MON(0x80)
+#define REG_MAXREG_VIN_MON
+
+enum lm3554_mode {
+ MODE_SHDN = 0,
+ MODE_INDIC,
+ MODE_TORCH,
+ MODE_FLASH,
+ MODE_VOUT,
+ MODE_VOUT_INDIC,
+ MODE_VOUT_TORCH,
+ MODE_VOUT_FLASH,
+};
+
+struct lm3554_chip_data {
+ struct device *dev;
+
+ struct led_classdev cdev_flash;
+ struct led_classdev cdev_torch;
+ struct led_classdev cdev_indicator;
+
+ struct lm3554_platform_data *pdata;
+
+ struct mutex lock;
+ struct regmap *regmap;
+ unsigned int last_flag;
+};
+
+/* chip initialize */
+static int __devinit lm3554_chip_init(struct lm3554_chip_data *chip)
+{
+ int ret;
+ unsigned int reg_val;
+ struct lm3554_platform_data *pdata = chip->pdata;
+
+ /* input and output pins configuration */
+ reg_val = pdata->pin_strobe | pdata->pin_tx1
+ | pdata->pin_tx2 | pdata->ledi_pin;
+ ret = regmap_update_bits(chip->regmap, REG_CONF1, 0xAC, reg_val);
+ if (ret < 0)
+ goto out;
+
+ return ret;
+out:
+ dev_err(chip->dev, "%s:i2c access fail to register\n", __func__);
+ return ret;
+}
+
+/* chip control */
+static void lm3554_control(struct lm3554_chip_data *chip,
+ u8 brightness, enum lm3554_mode opmode)
+{
+ int ret;
+ unsigned int reg_val;
+ struct lm3554_platform_data *pdata = chip->pdata;
+
+ ret = regmap_read(chip->regmap, REG_FLAG, >last_flag);
+ if (ret < 0)
+ goto out;
+ if (chip->last_flag)
+ dev_info(chip->dev, "LM3554 Last FLAG is 0x%x\n",
+chip->last_flag);
+ /* brightness 0 means shutdown */
+ if (!brightness)
+ opmode = MODE_SHDN;
+
+ switch (opmode) {
+ case MODE_TORCH:
+ if (pdata->pin_tx1 == LM3554_TX1_HW_TORCH) {
+ ret = regmap_update_bits(chip->regmap,
+REG_CONF1, 0x80, 0x80);
+ if (ret < 0)
+ goto out;
+ opmode = MODE_SHDN;
+ }
+ ret = regmap_update_bits(chip->regmap,
+REG_TORCH,
[PATCH] i2c: sis964: bus driver
This patch is a driver for SiS964 I2C bus. It was forked from i2c-sis630 and modified with SiS datasheets. Tested with kmemleak. Signed-off-by: Amaury Decrême --- Documentation/i2c/busses/i2c-sis964 | 34 ++ MAINTAINERS | 16 + drivers/i2c/busses/Kconfig | 12 +- drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-sis964.c | 575 +++ include/linux/pci_ids.h |1 + 6 files changed, 638 insertions(+), 1 deletions(-) create mode 100644 Documentation/i2c/busses/i2c-sis964 create mode 100644 drivers/i2c/busses/i2c-sis964.c diff --git a/Documentation/i2c/busses/i2c-sis964 b/Documentation/i2c/busses/i2c-sis964 new file mode 100644 index 000..a831f1a --- /dev/null +++ b/Documentation/i2c/busses/i2c-sis964 @@ -0,0 +1,34 @@ +Kernel driver i2c-sis964 + +Supported adapters: + * Silicon Integrated Systems Corp (SiS) + 964 chipset (Datasheet by SiS) + * Possible other SiS chipsets with the same registers and clocks + +Author:Amaury Decrême + +Module Parameters +- + +* force = [1|0]Forcibly enable the SIS964. DANGEROUS! + This can be interesting for chipsets not named + above to check if it works for you chipset, + but DANGEROUS! + +* low_clock = [1|0]1 = Set Host Master Clock to 28KHz (defaut 56Khz) + +Description +--- + +This SMBus driver is known to work on motherboards with the SiS964 chipset. + +If you see something like this: + +00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] + +in your 'lspci' output , then this driver is for your chipset. + +Thank You +- +Alexander Malysh +- Who has written i2c-sis630, from which i2c-sis964 is forked diff --git a/MAINTAINERS b/MAINTAINERS index eb22272..4a11805 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6179,6 +6179,22 @@ S: Maintained F: Documentation/i2c/busses/i2c-sis96x F: drivers/i2c/busses/i2c-sis96x.c +SIS 964 I2C/SMBUS DRIVER +M: "Amaury Decrême" +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/i2c/busses/i2c-sis96i4 +F: drivers/i2c/busses/i2c-sis964.c + +SIS FRAMEBUFFER DRIVER +M: Thomas Winischhofer +W: http://www.winischhofer.net/linuxsisvga.shtml +S: Maintained +F: Documentation/fb/sisfb.txt +F: drivers/video/sis/ +F: include/video/sisfb.h + +SIS USB2VGA DRIVER SIS FRAMEBUFFER DRIVER M: Thomas Winischhofer W: http://www.winischhofer.net/linuxsisvga.shtml diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 7244c8b..8dc9f90 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -189,8 +189,18 @@ config I2C_SIS630 This driver can also be built as a module. If so, the module will be called i2c-sis630. +config I2C_SIS964 + tristate "SiS 964" + depends on PCI && EXPERIMENTAL + help + If you say yes to this option, support will be included for the SiS + 964 SMBus (a subset of I2C) interfaces. + + This driver can also be built as a module. If so, the module + will be called i2c-sis964. + config I2C_SIS96X - tristate "SiS 96x" + tristate "SiS 96x (but SiS964)" depends on PCI help If you say yes to this option, support will be included for the SiS diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index ce3c2be..b985bc8 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_I2C_NFORCE2_S4985) += i2c-nforce2-s4985.o obj-$(CONFIG_I2C_PIIX4)+= i2c-piix4.o obj-$(CONFIG_I2C_SIS5595) += i2c-sis5595.o obj-$(CONFIG_I2C_SIS630) += i2c-sis630.o +obj-$(CONFIG_I2C_SIS964) += i2c-sis964.o obj-$(CONFIG_I2C_SIS96X) += i2c-sis96x.o obj-$(CONFIG_I2C_VIA) += i2c-via.o obj-$(CONFIG_I2C_VIAPRO) += i2c-viapro.o diff --git a/drivers/i2c/busses/i2c-sis964.c b/drivers/i2c/busses/i2c-sis964.c new file mode 100644 index 000..9f4ed14 --- /dev/null +++ b/drivers/i2c/busses/i2c-sis964.c @@ -0,0 +1,575 @@ +/* +Copyright (c) 2012 Amaury Decrême + +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. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
Re: [RESEND PATCH 1/1] clk: add DT support for clock gating control
On 07/13/2012 05:19 AM, Rob Herring wrote:
What's implemented in Linux should not define the binding. The binding
should describe the hardware.
[...]
True, but not your problem to implement. A binding doesn't necessarily
mean there is a full Linux implementation. We just don't want to create
something only to find others need something completely different.
Ok, what about a DT describing the following for a simple register-based
clock gating controller and the corresponding gated-clock independent of
the controller. I am sure there are a bunch of SoCs out there that
control their clock gates by writing some bits to a register. If that
DT description matches your expectations, I ll prepare patches with
documentation and implementation for common clock framework.
Sebastian
--
/* Simple clock gating controller based on bitmasks and register */
cgc: clock-gating-control@f100 {
compatible = "clock-gating-control-register";
reg = <0xf100 0x4>;
/* Clock gating control with one bit at bit position 0
enable with (1<<0), disable with (0<<0) */
cgctrl_usb0: cgc_usb0 {
clock-gating-control,shift = <0>;
clock-gating-control,mask = <1>;
clock-gating-control,enable = <1>;
clock-gating-control,disable = <0>;
};
/* Clock gating control with two bits at bit position 1-2
enable with (2<<1), disable with (0<<1) */
cgctrl_sata: cgc_sata {
clock-gating-control,shift = <1>;
clock-gating-control,mask = <3>;
clock-gating-control,enable = <2>;
clock-gating-control,disable = <0>;
};
};
/* Generic clock gate description that can be used with
any clock gating controller */
cg_usb0: clockgate@0 {
compatible = "gated-clock";
#clock-cells = <0>;
clocks = <>;
clock-gate-control = <_usb0>;
};
--
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: ARM: why smp_mb() is not needed in the "__mutex_fastpath_lock" and "__mutex_fastpath_unlock" functions
On Fri, Jul 13, 2012 at 10:10:52AM +0100, shan kang wrote: > For example, in the following scenario, Process2 may get the wrong value; > Process1: > mutex_lock(); > write data; (store operation) > mutex_unlock(); > > Process2: > mutex_lock(); > read data; (load operation) > mutex_unlock(); Yes, it looks like we can screw things up in the uncontended case (where nobody blocks on the mutex). We could add an smp_mb after the lock operation and another one before the unlock, but I'm tempted just to use asm-generic/mutex-dec.h instead. The latter approach will subtly change the current behaviour, so I'll post a patch when I'm happy with it. Curious: did you find this by inspection or did you observe it going wrong? Cheers, Will -- 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/
[3.5-rc6+] mei: irq: request_threaded_irq is missing the IRQF_ONESHOT flag
Hi, while dealing with [1], I saw this mei-related infos in dmesg when doing a suspend + resume (see [1] for more logs): [17046.348467] [] mei_pci_suspend+0x78/0xd0 [mei] [17047.460315] mei :00:16.0: irq 47 for MSI/MSI-X [17047.460512] mei :00:16.0: request_threaded_irq failed: irq = 47. I am not sure whom to address with the issue - so I just asked on #linux-rt and Thomas responded: [ 13-Jul-2012: German local-time (UTC+2) ] ... [11:03:40] request_threaded_irq is missing the IRQF_ONESHOT flag ... [11:24:18] anyone can fix it by sending a patch which adds the flag :) Futhermore, I found those commits, so I added folks from there to this BR: 16a50b1 mei: pci_resume: set IRQF_ONESHOT for msi request_threaded_irq aa189ec misc: mei: set IRQF_ONESHOT for msi request_threaded_irq If you need more infos and/or logs, please let me know. Feel free to add: Reported-by: Sedat Dilek Kind Regards, - Sedat (dileks on IRC) - [1] http://marc.info/?l=linux-kernel=134216822724119=2 -- 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 0/6] KGDB/KDB FIQ (NMI) debugger
On Thu, Jul 05, 2012 at 05:02:12PM -0700, Colin Cross wrote: [...] > KGDB can obviously only be enabled on development > devices, although perhaps a more limited KDB could be left enabled. Um, I would argue about 'obviously'. :-) It doesn't require CONFIG_DEBUG_INFO (-g) or something like this, so if the concern is the size (which is about 30..40 KB), then it is all manageable. If we want it to be smaller, we should just work on making KGDB/KDB more modular, so that we can exclude non-production features. > > The FIQ debugger is a facility that can be used to debug situations > > when the kernel stuck in uninterruptable sections, e.g. the kernel > > infinitely loops or deadlocked in an interrupt or with interrupts > > disabled. On some development boards there is even a special NMI > > button, which is very useful for debugging weird kernel hangs. > > > > And FIQ is basically an NMI, it has a higher priority than IRQs, and > > upon IRQ exception FIQs are not disabled. It is still possible to > > disable FIQs (as well as some "NMIs" on other architectures), but via > > special means. > > > > So, here FIQs and NMIs are synonyms, but in the code I use NMI term > > for arch-independent code, and FIQs for ARM code. > > Unfortunately, FIQs have been repurposed as secure interrupts on every > ARM SoC that supports TrustZone, which is basically all of the latest > generation, as well as a few of the previous generation. When an FIQ > arrives, the cpu traps into the secure mode, generally running a > separate secure OS written by a 3rd party vendor. We've tried to get > some SoC secure implementations to drop out of secure mode and into > the FIQ exception vector for specific irqs, with the registers set up > to allow the FIQ handler to return back to the original execution > point, but it's been successful. It's pity, and this just shows that recent SOCs have a somewhat limited debugging facilities. There are countless times when I was able to debug a hang simply by hitting an NMI button on a reference board (not ARM, tho) and just reading the trace. Having any (even a watchdog) NMI connected to a kernel would be enough to make things better. Btw, these patches' approach works even if we can't reroute arbitrary interrupts to FIQs (like we do for serial lines). [...] > > This might look as a drastic change, but it is not. There is actually > > no difference whether you have sync or async shell, or at least I > > couldn't find any use-case where this would matter at all. Anyways, > > it is still possible to do async shell in KDB, just don't see any > > need for this. > > I think it could be an issue if KDB stopped execution whenever it > received any character. Serial ports are often noisy, especially when > muxed over another port (we often use serial over the headset > connector). Noise on the async command line just causes characters > that are ignored, on a command line that blocked execution noise would > be catastrophic. Aha, that's the real use-case, thanks! I started hacking the KDB to add the async shell support, but then I realized that we still don't need all the complexity. If the only purpose is to be safe from the noise, then we can just do "knocking" before entering the debugger. The thing is, we even have a standard sequence for entering KDB, it is GDB-protocol command $3#33, so it actually makes sense to implement this. This would be the only async command, and it doesn't affect anything but the new code. I prepared a separate patch for this. [...] > One of the nice features in FIQ debugger is the "console" command, > which causes all incoming serial characters to get passed to a console > device provided by the FIQ debugger, and characters from the console > to go out the serial port (when it is enabled). That way you can > still have the console when you want it, but only one driver talking > to the hardware. This is surely a nice feature, and we have a chance to make it work with this scheme too. For example, we can reroute FIQ to IRQ, and reinitialize the tty device, so that it would grab the IRQ, then we can give uart back. Surely there are some implementation details that makes it not that easy, but it is definitely doable. Thanks! -- Anton Vorontsov Email: cbouatmai...@gmail.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: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Fri, 13 Jul 2012, Mike Galbraith wrote: > On Thu, 2012-07-12 at 15:31 +0200, Thomas Gleixner wrote: > > Bingo, that makes it more likely that this is caused by copying w/o > > initializing the lock and then freeing the original structure. > > > > A quick check for memcpy finds that __btrfs_close_devices() does a > > memcpy of btrfs_device structs w/o initializing the lock in the new > > copy, but I have no idea whether that's the place we are looking for. > > Thanks a bunch Thomas. I doubt I would have ever figured out that lala > land resulted from _copying_ a lock. That's one I won't be forgetting > any time soon. Box not only survived a few thousand xfstests 006 runs, > dbench seemed disinterested in deadlocking virgin 3.0-rt. Cute. It think that the lock copying caused the deadlock problem as the list pointed to the wrong place, so we might have ended up with following down the wrong chain when walking the list as long as the original struct was not freed. That beast is freed under RCU so there could be a rcu read side critical section fiddling with the old lock and cause utter confusion. /me goes and writes a nastigram^W proper changelog > btrfs still locks up in my enterprise kernel, so I suppose I had better > plug your fix into 3.4-rt and see what happens, and go beat hell out of > virgin 3.0-rt again to be sure box really really survives dbench. A test against 3.4-rt sans enterprise mess might be nice as well. 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/
