Re: [GIT PULL] uprobes: pre-filtering
* Srikar Dronamraju wrote: > The other alternative is to extend the current abi and pass > the prefilter option. Should we extend the abi for userspace > tracing is obviously debatable. That's the obvious path to go - why add something to the kernel if user-space cannot make use of it? 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] tools lib traceevent: Handle dynamic array's element size properly
* Arnaldo Carvalho de Melo wrote: > Em Tue, Jan 22, 2013 at 02:16:47PM +0100, Jiri Olsa escreveu: > > On Mon, Jan 21, 2013 at 11:45:42PM -0500, Steven Rostedt wrote: > > > This is only used in this function (the field_dynamic_elem_size() is > > > only called here). Can we not add the field->type_dyn, and just use a > > > local variable here. You just need to make sure you free it correctly. > > > > ook, will send v2 > > Waiting for this fix, just got 'perf test' crashing on it again :-) > > Till then I implemented 'perf test --skip': Hm, I think perf test should fork() a testing thread and be robust against a child catching a SIGSEGV? That would also protect against a test corrupting perf test itself. 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] backlight: add an AS3711 PMIC backlight driver
Hi Jingoo Han
On Fri, 25 Jan 2013, Jingoo Han wrote:
> On Wednesday, January 09, 2013 2:55 AM, Guennadi Liakhovetski wrote
> >
> > This is an initial commit of a backlight driver, using step-up DCDC power
> > supplies on AS3711 PMIC. Only one mode has actually been tested, several
> > further modes have been implemented "dry," but disabled to avoid accidental
> > hardware damage. Anyone wishing to use any of those modes will have to
> > modify the driver.
> >
> > Signed-off-by: Guennadi Liakhovetski
>
> CC'ed Andrew Morton.
>
> Hi Guennadi Liakhovetski,
>
> I have reviewed this patch with AS3711 datasheet.
> I cannot find any problems. It looks good.
Thanks for the review.
> However, some hardcoded numbers need to be changed
> to the bit definitions.
Which specific hardcoded values do you mean? A while ago in a discussion
on one of kernel mailing lists a conclusion has been made, that macros do
not always improve code readability. E.g. in a statement like this
+ case AS3711_SU2_CURR_AUTO:
+ if (pdata->su2_auto_curr1)
+ ctl = 2;
+ if (pdata->su2_auto_curr2)
+ ctl |= 8;
+ if (pdata->su2_auto_curr3)
+ ctl |= 0x20;
making it
+ case AS3711_SU2_CURR_AUTO:
+ if (pdata->su2_auto_curr1)
+ ctl = SU2_AUTO_CURR1;
would hardly make it more readable. IMHO it is already pretty clear, that
bit 1 enables the current-1 sink. As long as these fields are only used at
one location in the driver (and they are), using a macro and defining it
elsewhere only makes it harder to see actual values. Speaking of this, a
comment like
/*
* Select, which current sinks shall be used for automatic
* feedback selection
*/
would help much more than any macro names. But as it stands, I think the
current version is also possible to understand :-) If desired, however,
comments can be added in an incremental patch.
Thanks
Guennadi
> Acked-by: Jingoo Han
>
>
> Best regards,
> Jingoo Han
>
> > ---
> >
> > Tested on sh73a0-based kzm9g board. As the commit message says, only one
> > mode has been tested and is enabled. That mode copies the sample code from
> > the manufacturer. Deviations from that code proved to be fatal for the
> > hardware...
> >
> > drivers/video/backlight/Kconfig |7 +
> > drivers/video/backlight/Makefile|1 +
> > drivers/video/backlight/as3711_bl.c | 379
> > +++
> > 3 files changed, 387 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/video/backlight/as3711_bl.c
> >
> > diff --git a/drivers/video/backlight/Kconfig
> > b/drivers/video/backlight/Kconfig
> > index 765a945..6ef0ede 100644
> > --- a/drivers/video/backlight/Kconfig
> > +++ b/drivers/video/backlight/Kconfig
> > @@ -390,6 +390,13 @@ config BACKLIGHT_TPS65217
> > If you have a Texas Instruments TPS65217 say Y to enable the
> > backlight driver.
> >
> > +config BACKLIGHT_AS3711
> > + tristate "AS3711 Backlight"
> > + depends on BACKLIGHT_CLASS_DEVICE && MFD_AS3711
> > + help
> > + If you have an Austrian Microsystems AS3711 say Y to enable the
> > + backlight driver.
> > +
> > endif # BACKLIGHT_CLASS_DEVICE
> >
> > endif # BACKLIGHT_LCD_SUPPORT
> > diff --git a/drivers/video/backlight/Makefile
> > b/drivers/video/backlight/Makefile
> > index e7ce729..d3e188f 100644
> > --- a/drivers/video/backlight/Makefile
> > +++ b/drivers/video/backlight/Makefile
> > @@ -45,3 +45,4 @@ obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> > obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
> > obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
> > obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
> > +obj-$(CONFIG_BACKLIGHT_AS3711) += as3711_bl.o
> > diff --git a/drivers/video/backlight/as3711_bl.c
> > b/drivers/video/backlight/as3711_bl.c
> > new file mode 100644
> > index 000..c6bc65d
> > --- /dev/null
> > +++ b/drivers/video/backlight/as3711_bl.c
> > @@ -0,0 +1,379 @@
> > +/*
> > + * AS3711 PMIC backlight driver, using DCDC Step Up Converters
> > + *
> > + * Copyright (C) 2012 Renesas Electronics Corporation
> > + * Author: Guennadi Liakhovetski,
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the version 2 of the GNU General Public License as
> > + * published by the Free Software Foundation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +enum as3711_bl_type {
> > + AS3711_BL_SU1,
> > + AS3711_BL_SU2,
> > +};
> > +
> > +struct as3711_bl_data {
> > + bool powered;
> > + const char *fb_name;
> > + struct device *fb_dev;
> > + enum as3711_bl_type type;
> > + int brightness;
> > + struct backlight_device *bl;
> > +};
> > +
Re: [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote: > On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote: > > Added a new driver for the usb part of control module. This has an API > > to power on the USB2 phy and an API to write to the mailbox depending on > > whether MUSB has to act in host mode or in device mode. > > > > Writing to control module registers for doing the above task which was > > previously done in omap glue and in omap-usb2 phy will be removed. > > > diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt > > b/Documentation/devicetree/bindings/usb/usb-phy.txt > > This file seems to be specific to the TI USB PHYs, not all USB PHYs; > shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match > the compatible value it documents, giving ti,omap-usb2.txt? could be, but that can be done as a separate patch. It's not part of $SUBJECT. > > add the address of control module dev conf register until a driver for > > control module is added > > > > +Optional properties: > > + - ctrl_module : phandle of the control module used by PHY driver to power > > on > > + the PHY. > > DT property names generally use - not _ as the word separator. fair enough, Kishon, can you fix this up ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/6] sched: split out css_online/css_offline from tg creation/destruction
* Tejun Heo wrote: > On Thu, Jan 24, 2013 at 11:01:34AM +0100, Ingo Molnar wrote: > > Acked-by: Ingo Molnar > > Ingo, if you don't objecdt, I'll take these through cgroup/for-3.9 > branch with other cgroup changes. Pleaes holler if you object. That's fine with me, it should not interact with anything pending in (or planned for) the scheduler tree for this cycle. 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: [tip:x86/debug] x86/EFI: Properly init-annotate BGRT code
>>> On 24.01.13 at 23:28, Josh Triplett wrote: > On Thu, Jan 24, 2013 at 12:34:21PM -0800, tip-bot for Jan Beulich wrote: >> Commit-ID: 13f0e4d2b9e2209f13d5a4122478eb79e6136870 >> Gitweb: > http://git.kernel.org/tip/13f0e4d2b9e2209f13d5a4122478eb79e6136870 >> Author: Jan Beulich >> AuthorDate: Fri, 23 Nov 2012 16:30:07 + >> Committer: Ingo Molnar >> CommitDate: Thu, 24 Jan 2013 17:12:18 +0100 >> >> x86/EFI: Properly init-annotate BGRT code >> >> These items are only ever referenced from initialization code. > > Not true, and this patch will break the BGRT code. bgrt_init, which > does indeed have an __init annotation, stores bgrt_image and > bgrt_image_size into the .private and .size fields of a sysfs > bin_attribute, which does *not* have an __initdata annotation, and which > will get read whenever the user reads the corresponding sysfs attribute. Copying init-only data into a sysfs structure is no problem at all - that structure obviously is non-__initdata and hence can be read at any time. It was a different thing if .private and/or .size stored _pointers_ to one of the two variables in question. Jan -- 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 v1 1/8] usb: otg: palmas-usb: make palmas-usb as a comparator driver
Hi, On Fri, Jan 25, 2013 at 08:42:24AM +0530, Kishon Vijay Abraham I wrote: > palmas-usb is made as a comparator driver to omap usb2 phy, so that > omap usb can make use of palmas for srp and also to set vbus. > > Signed-off-by: Kishon Vijay Abraham I doesn't apply. palmas-usb isn't in mainline -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] mutex: use spin_[un]lock instead of arch_spin_[un]lock
* Andrew Morton wrote: > On Thu, 24 Jan 2013 17:22:45 +0800 > Yuanhan Liu wrote: > > > Use spin_[un]lock instead of arch_spin_[un]lock in mutex-debug.h so > > that we can collect the lock statistics of spin_lock_mutex from > > /proc/lock_stat. So, as per the discussion we don't want this patch, because we are using raw locks there to keep mutex lockdep overhead low. The value of lockdep-checking such a basic locking primitive is minimal - it's rarely tweaked and if it breaks we won't have a bootable kernel to begin with. So instead I suggested a different patch: adding a comment to explain why we don't lockdep-cover the mutex code spinlocks. > Also, I believe your patch permits this cleanup: > > --- a/kernel/mutex-debug.h~mutex-use-spin_lock-instead-of-arch_spin_lock-fix > +++ a/kernel/mutex-debug.h > @@ -42,14 +42,12 @@ static inline void mutex_clear_owner(str > struct mutex *l = container_of(lock, struct mutex, wait_lock); \ > \ > DEBUG_LOCKS_WARN_ON(in_interrupt());\ > - local_irq_save(flags); \ > - spin_lock(lock);\ > + spin_lock_irqsave(lock, flags); \ Yes, I mentioned that yesterday, but we really don't want the change to begin with. 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>>> On 24.01.13 at 19:59, Olaf Hering wrote: > On Thu, Jan 24, KY Srinivasan wrote: > > >> > Question is - considering you stated that this is supported >> > starting in Win8, doesn't Hyper-V itself announce that >> > capability in some explicit way? >> >> Thanks Jan. Unfortunately I don't think tis interrupt delivery model >> is specified via a "feature" bit (I will check with the Windows guys). >> Perhaps, we can have a Hyper-V specific compilation switch to address >> the Xen emulation issue. > > Would that really help if both pvops XEN_PVHVM and HYPERV are enabled in > the config? I assume at this point the access to the DMI data is not yet > possible. As just said in another reply - with XEN_PVHVM, there's no problem, since Xen gets checked for first. There's only a problem when !XEN_PVHVM, because in that case Hyper-V will be probed for. And the problem can only get bigger when on top of that the out-of-tree PV drivers are intended to be used. Jan -- 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>>> On 24.01.13 at 20:03, KY Srinivasan wrote: > I was under the impression that only Dom0 Xen would emulate Hyper-V. How that? It's the hypervisor that does the emulation, and obviously not for Dom0, but for (HVM) DomU-s. Jan -- 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>>> On 24.01.13 at 20:10, "H. Peter Anvin" wrote: > I also have to point out the obvious problem with Xen masquerading as HyperV > without implementing the same feature set... I can't resist to state that this is what feature bits have been introduced for in CPUID leaves. As long as Xen's shim doesn't advertise a feature bit it doesn't implement, all should be fine. Jan -- 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] sched: Fix print format for u64
On Thu, Jan 24, 2013 at 11:19 PM, Ingo Molnar wrote: > > * Fabio Estevam wrote: > >> On Thu, Jan 24, 2013 at 12:19 PM, Ingo Molnar wrote: >> >> > I suppose - is this patch warning-free both on 64-bit and 32-bit >> > systems? >> >> Yes, just confirmed that this patch is warning-free on both 64-bit and >> 32-bit machines. > > Apparently it's not all good, see the warning attached below. Yeah this patch is broken; this is not properly fixable as is without #ifdefs (or fixing the insanity that is atomic64_read). Specifically: On some architectures (e.g. x86_64) atomic64_read is typed long On some others (e.g. x86-32) it's typed long long On yet others (e.g. arm) it's typed u64 I think the easiest way to fix it would be instead to promote the read into a local u64 and print that. > > Thanks, > > Ingo > > - Forwarded message from kbuild test robot - > > Date: Fri, 25 Jan 2013 14:02:05 +0800 > From: kbuild test robot > To: Fabio Estevam > Cc: Ingo Molnar > Subject: [next:akpm 188/817] kernel/sched/debug.c:225:2: warning: format > '%llu' expects argument > of type 'long long unsigned int', but argument 4 has type 'long int' > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm > head: 5d2ee7d8b03bfe3b90325d736d8e544d0394efa7 > commit: 2d58000fd2020255af63ee92c8d0ef615f6c4ade [188/817] sched: Fix print > format for u64 > config: make ARCH=x86_64 allmodconfig > > All warnings: > >kernel/sched/debug.c: In function 'print_cfs_rq': >>> kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type >>> 'long long unsigned int', but argument 4 has type 'long int' [-Wformat] >>> kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type >>> 'long long unsigned int', but argument 3 has type 'long int' [-Wformat] > > vim +225 kernel/sched/debug.c > >209 spread = max_vruntime - MIN_vruntime; >210 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread", >211 SPLIT_NS(spread)); >212 spread0 = min_vruntime - rq0_min_vruntime; >213 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread0", >214 SPLIT_NS(spread0)); >215 SEQ_printf(m, " .%-30s: %d\n", "nr_spread_over", >216 cfs_rq->nr_spread_over); >217 SEQ_printf(m, " .%-30s: %d\n", "nr_running", > cfs_rq->nr_running); >218 SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight); >219 #ifdef CONFIG_FAIR_GROUP_SCHED >220 #ifdef CONFIG_SMP >221 SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg", >222 cfs_rq->runnable_load_avg); >223 SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", >224 cfs_rq->blocked_load_avg); > > 225 SEQ_printf(m, " .%-30s: %llu\n", "tg_load_avg", >226 atomic64_read(_rq->tg->load_avg)); >227 SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", >228 cfs_rq->tg_load_contrib); >229 SEQ_printf(m, " .%-30s: %d\n", "tg_runnable_contrib", >230 cfs_rq->tg_runnable_contrib); >231 SEQ_printf(m, " .%-30s: %d\n", "tg->runnable_avg", >232 atomic_read(_rq->tg->runnable_avg)); >233 #endif > > --- > 0-DAY kernel build testing backend Open Source Technology Center > http://lists.01.org/mailman/listinfo/kbuild Intel Corporation > > - End forwarded message - > -- 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] cpuset: fix cpuset_print_task_mems_allowed() vs rename() race
On 2013/1/25 15:26, Al Viro wrpte: > On Fri, Jan 25, 2013 at 03:09:48PM +0800, Li Zefan wrote: >> rename() will change dentry->d_name. The result of this race can >> be worse than seeing partially rewritten name, but we might access >> a stale pointer because rename() will re-allocate memory to hold >> a longer name. >> >> It's safe in the protection of dentry->d_lock. >> >> Signed-off-by: Li Zefan >> --- >> kernel/cpuset.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/kernel/cpuset.c b/kernel/cpuset.c >> index 16be7c9..b2476c2 100644 >> --- a/kernel/cpuset.c >> +++ b/kernel/cpuset.c >> @@ -2606,8 +2606,12 @@ void cpuset_print_task_mems_allowed(struct >> task_struct *tsk) >> >> dentry = task_cs(tsk)->css.cgroup->dentry; >> spin_lock(_buffer_lock); >> + >> +spin_lock(>d_lock); >> snprintf(cpuset_name, CPUSET_NAME_LEN, >> dentry ? (const char *)dentry->d_name.name : "/"); > > Ahem... Can dentry actually be NULL here? If not, this conditional > is bogus; otherwise, spin_lock(>d_lock) is going to blow up... oops, my fault...It's NULL if cpuset is not mounted. -- 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 RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>>> On 24.01.13 at 20:04, "H. Peter Anvin" wrote: > Can't you discover Xen emulation by looking for Xen first? Or does Xen go > "stealth"? That's already being done - the ordering currently is Xen, VMWare, Hyper-V, KVM. I.e. there's only a problem when !CONFIG_XEN_PVHVM. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 03:04 PM, Jason Wang wrote:
> On 01/25/2013 02:42 PM, Wanlong Gao wrote:
>> On 01/25/2013 02:12 PM, Jason Wang wrote:
>>> On 01/25/2013 01:40 PM, Wanlong Gao wrote:
On 01/25/2013 01:13 PM, Jason Wang wrote:
> On 01/25/2013 12:20 PM, Wanlong Gao wrote:
>> On 01/25/2013 11:28 AM, Jason Wang wrote:
>>> On 01/21/2013 07:25 PM, Wanlong Gao wrote:
Split out the clean affinity function to virtnet_clean_affinity().
Cc: Rusty Russell
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Eric Dumazet
Cc: virtualizat...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Signed-off-by: Wanlong Gao
---
V5->V6: NEW
drivers/net/virtio_net.c | 67
+++-
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 70cd957..1a35a8c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
net_device *dev, u16 vid)
return 0;
}
-static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
+static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
{
int i;
int cpu;
- /* In multiqueue mode, when the number of cpu is equal to the
number of
- * queue pairs, we let the queue pairs to be private to one cpu
by
- * setting the affinity hint to eliminate the contention.
- */
- if ((vi->curr_queue_pairs == 1 ||
- vi->max_queue_pairs != num_online_cpus()) && set) {
- if (vi->affinity_hint_set)
- set = false;
- else
- return;
- }
-
- if (set) {
- i = 0;
- for_each_online_cpu(cpu) {
- virtqueue_/set_affinity(vi->rq[i].vq, cpu);
- virtqueue_set_affinity(vi->sq[i].vq, cpu);
- *per_cpu_ptr(vi->vq_index, cpu) = i;
- i++;
- }
-
- vi->affinity_hint_set = true;
- } else {
- for(i = 0; i < vi->max_queue_pairs; i++) {
+ if (vi->affinity_hint_set) {
+ for (i = 0; i < vi->max_queue_pairs; i++) {
virtqueue_set_affinity(vi->rq[i].vq, -1);
virtqueue_set_affinity(vi->sq[i].vq, -1);
}
i = 0;
- for_each_online_cpu(cpu)
+ for_each_online_cpu(cpu) {
+ if (cpu == hcpu)
+ continue;
*per_cpu_ptr(vi->vq_index, cpu) =
++i % vi->curr_queue_pairs;
+ }
>>> Some questions here:
>>>
>>> - Did we need reset the affinity of the queue here like the this?
>>>
>>> virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>>> virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>> I think no, we are going to unset the affinity of all the set queues,
>> include hcpu.
>>
>>> - Looks like we need also reset the percpu index when
>>> vi->affinity_hint_set is false.
>> Yes, follow this and the comment on [1/3].
>>
>>> - Does this really need this reset? Consider we're going to reset the
>>> percpu in CPU_DEAD?
>> I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong
>> queue
>> on the dying CPU.
> Didn't understand this. What does 'wrong queue' here mean? Looks like
> you didn't change the preferable queue of the dying CPU and just change
> all others.
How about setting the vq index to -1 on hcpu when doing DOWN_PREPARE?
So that let it select txq to 0 when the CPU is dying.
>>> Looks safe, so look like what you're going to solve here is the the race
>>> between cpu hotplug and virtnet_set_channels(). A possible better
>>> solution is to serialize them by protecting virtnet_set_queues() by
>>> get_online_cpus() also. After this, we can make sure the number of
>>> channels were not changed during cpu hotplug, and looks like there's no
>>> need to reset the preferable queues in DOWN_PREPARE.
>>>
>>> What's your opinion?
>> IMHO, serialize every time will take lock and may slow down this path,
>> but the hot unplug path will be more cold than it. So
Re: [PATCH] cpuset: fix cpuset_print_task_mems_allowed() vs rename() race
On Fri, Jan 25, 2013 at 03:09:48PM +0800, Li Zefan wrote: > rename() will change dentry->d_name. The result of this race can > be worse than seeing partially rewritten name, but we might access > a stale pointer because rename() will re-allocate memory to hold > a longer name. > > It's safe in the protection of dentry->d_lock. > > Signed-off-by: Li Zefan > --- > kernel/cpuset.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/kernel/cpuset.c b/kernel/cpuset.c > index 16be7c9..b2476c2 100644 > --- a/kernel/cpuset.c > +++ b/kernel/cpuset.c > @@ -2606,8 +2606,12 @@ void cpuset_print_task_mems_allowed(struct task_struct > *tsk) > > dentry = task_cs(tsk)->css.cgroup->dentry; > spin_lock(_buffer_lock); > + > + spin_lock(>d_lock); > snprintf(cpuset_name, CPUSET_NAME_LEN, >dentry ? (const char *)dentry->d_name.name : "/"); Ahem... Can dentry actually be NULL here? If not, this conditional is bogus; otherwise, spin_lock(>d_lock) is going to blow up... -- 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] sched: Fix print format for u64
* Fabio Estevam wrote: > On Thu, Jan 24, 2013 at 12:19 PM, Ingo Molnar wrote: > > > I suppose - is this patch warning-free both on 64-bit and 32-bit > > systems? > > Yes, just confirmed that this patch is warning-free on both 64-bit and > 32-bit machines. Apparently it's not all good, see the warning attached below. Thanks, Ingo - Forwarded message from kbuild test robot - Date: Fri, 25 Jan 2013 14:02:05 +0800 From: kbuild test robot To: Fabio Estevam Cc: Ingo Molnar Subject: [next:akpm 188/817] kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long int' tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm head: 5d2ee7d8b03bfe3b90325d736d8e544d0394efa7 commit: 2d58000fd2020255af63ee92c8d0ef615f6c4ade [188/817] sched: Fix print format for u64 config: make ARCH=x86_64 allmodconfig All warnings: kernel/sched/debug.c: In function 'print_cfs_rq': >> kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type >> 'long long unsigned int', but argument 4 has type 'long int' [-Wformat] >> kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type >> 'long long unsigned int', but argument 3 has type 'long int' [-Wformat] vim +225 kernel/sched/debug.c 209 spread = max_vruntime - MIN_vruntime; 210 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread", 211 SPLIT_NS(spread)); 212 spread0 = min_vruntime - rq0_min_vruntime; 213 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread0", 214 SPLIT_NS(spread0)); 215 SEQ_printf(m, " .%-30s: %d\n", "nr_spread_over", 216 cfs_rq->nr_spread_over); 217 SEQ_printf(m, " .%-30s: %d\n", "nr_running", cfs_rq->nr_running); 218 SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight); 219 #ifdef CONFIG_FAIR_GROUP_SCHED 220 #ifdef CONFIG_SMP 221 SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg", 222 cfs_rq->runnable_load_avg); 223 SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", 224 cfs_rq->blocked_load_avg); > 225 SEQ_printf(m, " .%-30s: %llu\n", "tg_load_avg", 226 atomic64_read(_rq->tg->load_avg)); 227 SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", 228 cfs_rq->tg_load_contrib); 229 SEQ_printf(m, " .%-30s: %d\n", "tg_runnable_contrib", 230 cfs_rq->tg_runnable_contrib); 231 SEQ_printf(m, " .%-30s: %d\n", "tg->runnable_avg", 232 atomic_read(_rq->tg->runnable_avg)); 233 #endif --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation - End forwarded message - -- 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] cgroup: add lock validation in check_for_release()
There was a long-standing bug that this function was called without any
lock. Add a check to prevent similar issue.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 776ff75..3d21adf 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5028,13 +5028,20 @@ int cgroup_is_descendant(const struct cgroup *cgrp,
struct task_struct *task)
static void check_for_release(struct cgroup *cgrp)
{
- /* All of these checks rely on RCU to keep the cgroup
-* structure alive */
+ /*
+* All of these checks rely on RCU or cgroup_mutex to keep the cgroup
+* structure alive
+*/
+ rcu_lockdep_assert(rcu_read_lock_held() || cgroup_lock_is_held(),
+ "check_for_release() called witout proper locking");
+
if (cgroup_is_releasable(cgrp) && !atomic_read(>count)
&& list_empty(>children) && !cgroup_has_css_refs(cgrp)) {
- /* Control Group is currently removeable. If it's not
+ /*
+* Control Group is currently removable. If it's not
* already queued for a userspace notification, queue
-* it now */
+* it now
+*/
int need_schedule_work = 0;
raw_spin_lock(_list_lock);
if (!cgroup_is_removed(cgrp) &&
--
1.8.0.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/
[PATCH] cgroup: fix cgroup_path() vs rename() race
rename() will change dentry->d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
a longer name.
Use dentry_path_raw(), and this vfs API will take care of lockings.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 5d4c92e..776ff75 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1792,26 +1792,10 @@ int cgroup_path(const struct cgroup *cgrp, char *buf,
int buflen)
return 0;
}
- start = buf + buflen - 1;
+ start = dentry_path_raw(dentry, buf, buflen);
+ if (IS_ERR(start))
+ return PTR_ERR(start);
- *start = '\0';
- for (;;) {
- int len = dentry->d_name.len;
-
- if ((start -= len) < buf)
- return -ENAMETOOLONG;
- memcpy(start, dentry->d_name.name, len);
- cgrp = cgrp->parent;
- if (!cgrp)
- break;
-
- dentry = cgrp->dentry;
- if (!cgrp->parent)
- continue;
- if (--start < buf)
- return -ENAMETOOLONG;
- *start = '/';
- }
memmove(buf, start, buf + buflen - start);
return 0;
}
--
1.8.0.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: [BUG] panda board locks up on boot
Hi Steven, On 01/25/13 05:01, Steven Rostedt wrote: > I've recently started testing my work on arm boards and have found that > they both don't boot under the latest kernel anymore. I already posted > about my snowball board, but my panda board also locks up. > > I've bisected it down to this commit: > > commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 > Author: Russell King > Date: Fri Apr 13 12:27:37 2012 +0100 > > mmc: omap_hsmmc: remove private DMA API implementation > > Remove the private DMA API implementation from omap_hsmmc, making it > use entirely the DMA engine API. > > Tested-by: Tony Lindgren > Tested-by: Venkatraman S > Signed-off-by: Russell King > > > The commit before boots fine, when adding this commit, it locks up. > > I reverted the commit (with tweaks) against 3.8-rc4 and was able to get > my board booting again. Not sure what to do, but I wanted to let people > know. Care to post your kernel config file? -- Regards, Igor. -- 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] cpuset: fix cpuset_print_task_mems_allowed() vs rename() race
rename() will change dentry->d_name. The result of this race can be worse than seeing partially rewritten name, but we might access a stale pointer because rename() will re-allocate memory to hold a longer name. It's safe in the protection of dentry->d_lock. Signed-off-by: Li Zefan --- kernel/cpuset.c | 4 1 file changed, 4 insertions(+) diff --git a/kernel/cpuset.c b/kernel/cpuset.c index 16be7c9..b2476c2 100644 --- a/kernel/cpuset.c +++ b/kernel/cpuset.c @@ -2606,8 +2606,12 @@ void cpuset_print_task_mems_allowed(struct task_struct *tsk) dentry = task_cs(tsk)->css.cgroup->dentry; spin_lock(_buffer_lock); + + spin_lock(>d_lock); snprintf(cpuset_name, CPUSET_NAME_LEN, dentry ? (const char *)dentry->d_name.name : "/"); + spin_unlock(>d_lock); + nodelist_scnprintf(cpuset_nodelist, CPUSET_NODELIST_LEN, tsk->mems_allowed); printk(KERN_INFO "%s cpuset=%s mems_allowed=%s\n", -- 1.8.0.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 V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 02:42 PM, Wanlong Gao wrote:
> On 01/25/2013 02:12 PM, Jason Wang wrote:
>> On 01/25/2013 01:40 PM, Wanlong Gao wrote:
>>> On 01/25/2013 01:13 PM, Jason Wang wrote:
On 01/25/2013 12:20 PM, Wanlong Gao wrote:
> On 01/25/2013 11:28 AM, Jason Wang wrote:
>> On 01/21/2013 07:25 PM, Wanlong Gao wrote:
>>> Split out the clean affinity function to virtnet_clean_affinity().
>>>
>>> Cc: Rusty Russell
>>> Cc: "Michael S. Tsirkin"
>>> Cc: Jason Wang
>>> Cc: Eric Dumazet
>>> Cc: virtualizat...@lists.linux-foundation.org
>>> Cc: net...@vger.kernel.org
>>> Signed-off-by: Wanlong Gao
>>> ---
>>> V5->V6: NEW
>>>
>>> drivers/net/virtio_net.c | 67
>>> +++-
>>> 1 file changed, 38 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 70cd957..1a35a8c 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
>>> net_device *dev, u16 vid)
>>> return 0;
>>> }
>>>
>>> -static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
>>> +static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
>>> {
>>> int i;
>>> int cpu;
>>>
>>> - /* In multiqueue mode, when the number of cpu is equal to the
>>> number of
>>> -* queue pairs, we let the queue pairs to be private to one cpu
>>> by
>>> -* setting the affinity hint to eliminate the contention.
>>> -*/
>>> - if ((vi->curr_queue_pairs == 1 ||
>>> -vi->max_queue_pairs != num_online_cpus()) && set) {
>>> - if (vi->affinity_hint_set)
>>> - set = false;
>>> - else
>>> - return;
>>> - }
>>> -
>>> - if (set) {
>>> - i = 0;
>>> - for_each_online_cpu(cpu) {
>>> - virtqueue_/set_affinity(vi->rq[i].vq, cpu);
>>> - virtqueue_set_affinity(vi->sq[i].vq, cpu);
>>> - *per_cpu_ptr(vi->vq_index, cpu) = i;
>>> - i++;
>>> - }
>>> -
>>> - vi->affinity_hint_set = true;
>>> - } else {
>>> - for(i = 0; i < vi->max_queue_pairs; i++) {
>>> + if (vi->affinity_hint_set) {
>>> + for (i = 0; i < vi->max_queue_pairs; i++) {
>>> virtqueue_set_affinity(vi->rq[i].vq, -1);
>>> virtqueue_set_affinity(vi->sq[i].vq, -1);
>>> }
>>>
>>> i = 0;
>>> - for_each_online_cpu(cpu)
>>> + for_each_online_cpu(cpu) {
>>> + if (cpu == hcpu)
>>> + continue;
>>> *per_cpu_ptr(vi->vq_index, cpu) =
>>> ++i % vi->curr_queue_pairs;
>>> + }
>>>
>> Some questions here:
>>
>> - Did we need reset the affinity of the queue here like the this?
>>
>> virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>> virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
> I think no, we are going to unset the affinity of all the set queues,
> include hcpu.
>
>> - Looks like we need also reset the percpu index when
>> vi->affinity_hint_set is false.
> Yes, follow this and the comment on [1/3].
>
>> - Does this really need this reset? Consider we're going to reset the
>> percpu in CPU_DEAD?
> I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong
> queue
> on the dying CPU.
Didn't understand this. What does 'wrong queue' here mean? Looks like
you didn't change the preferable queue of the dying CPU and just change
all others.
>>> How about setting the vq index to -1 on hcpu when doing DOWN_PREPARE?
>>> So that let it select txq to 0 when the CPU is dying.
>> Looks safe, so look like what you're going to solve here is the the race
>> between cpu hotplug and virtnet_set_channels(). A possible better
>> solution is to serialize them by protecting virtnet_set_queues() by
>> get_online_cpus() also. After this, we can make sure the number of
>> channels were not changed during cpu hotplug, and looks like there's no
>> need to reset the preferable queues in DOWN_PREPARE.
>>
>> What's your opinion?
> IMHO, serialize every time will take lock and may slow down this path,
> but the hot unplug path will be more cold than it. So I prefer reset the
> preferable queues in DOWN_PREPARE but not serialize them. Agree?
I think it's ok since we're in
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
On Friday 25 January 2013 02:19 AM, Matt Porter wrote: On Thu, Jan 24, 2013 at 05:12:05AM +, Shilimkar, Santosh wrote: On Thursday 24 January 2013 02:19 AM, Matt Porter wrote: On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote: Matt, On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote: [...] Thanks for the catch, I'll add this in with your tested line as well for the series. BTW, since I'm dropping mmc support from this series, I'll move your patch into a separate series with only the mmc pieces. Fine by me -- 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/2] media: tvp7002: enable TVP7002 decoder for media controller based usage
From: Manjunath Hadli
add pad operations support for g_mbus_fmt, enum_mbus_code,
set_pad_format, get_pad_format and media_entity_init.
The device supports 1 output pad and no input pads.
Signed-off-by: Manjunath Hadli
Signed-off-by: Lad, Prabhakar
---
drivers/media/i2c/tvp7002.c | 132 +-
include/media/tvp7002.h |2 +
2 files changed, 130 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index fb6a5b5..312651e 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -41,9 +41,6 @@ MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer
driver");
MODULE_AUTHOR("Santiago Nunez-Corrales ");
MODULE_LICENSE("GPL");
-/* Module Name */
-#define TVP7002_MODULE_NAME"tvp7002"
-
/* I2C retry attempts */
#define I2C_RETRY_COUNT(5)
@@ -432,6 +429,9 @@ struct tvp7002 {
int streaming;
const struct tvp7002_preset_definition *current_preset;
+ /* mc related members */
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
};
/*
@@ -967,6 +967,109 @@ static const struct v4l2_ctrl_ops tvp7002_ctrl_ops = {
.s_ctrl = tvp7002_s_ctrl,
};
+/*
+ * tvp7002_enum_mbus_code() - Enum supported digital video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @code: pointer to subdev enum mbus code struct
+ *
+ * Enumerate supported digital video formats for pad.
+ */
+static int
+tvp7002_enum_mbus_code(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ /* Check pad index is valid */
+ if (code->pad != 0)
+ return -EINVAL;
+
+ /* Check requested format index is within range */
+ if (code->index != 0)
+ return -EINVAL;
+
+ code->code = V4L2_MBUS_FMT_YUYV10_1X20;
+
+ return 0;
+}
+
+/*
+ * tvp7002_set_pad_format() - set video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * set video format for pad.
+ */
+static int
+tvp7002_set_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
+{
+ struct tvp7002 *device = to_tvp7002(sd);
+ struct v4l2_dv_enum_preset e_preset;
+ int error;
+
+ /* Check pad index is valid */
+ if (fmt->pad != 0)
+ return -EINVAL;
+
+ /* Calculate height and width based on current standard */
+ error = v4l_fill_dv_preset_info(device->current_preset->preset,
+ _preset);
+ if (error)
+ return error;
+
+ fmt->format.code = V4L2_MBUS_FMT_YUYV10_1X20;
+ fmt->format.width = e_preset.width;
+ fmt->format.height = e_preset.height;
+ fmt->format.field = device->current_preset->scanmode;
+ fmt->format.colorspace = device->current_preset->color_space;
+ /* store for future use */
+ device->format = fmt->format;
+
+ return 0;
+}
+
+/*
+ * tvp7002_get_pad_format() - get video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * get video format for pad.
+ */
+static int
+tvp7002_get_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
+{
+ struct tvp7002 *device = to_tvp7002(sd);
+ struct v4l2_dv_enum_preset e_preset;
+ __u32 which = fmt->which;
+ int error;
+
+ /* Check pad index is valid */
+ if (fmt->pad != 0)
+ return -EINVAL;
+
+ if (which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+ fmt->format = device->format;
+ return 0;
+ }
+
+ /* Calculate height and width based on current standard */
+ error = v4l_fill_dv_preset_info(device->current_preset->preset,
+ _preset);
+ if (error)
+ return error;
+
+ fmt->format.code = V4L2_MBUS_FMT_YUYV10_1X20;
+ fmt->format.width = e_preset.width;
+ fmt->format.height = e_preset.height;
+ fmt->format.field = device->current_preset->scanmode;
+ fmt->format.colorspace = device->current_preset->color_space;
+
+ return 0;
+}
+
/* V4L2 core operation handlers */
static const struct v4l2_subdev_core_ops tvp7002_core_ops = {
.g_chip_ident = tvp7002_g_chip_ident,
@@ -1000,10 +1103,18 @@ static const struct v4l2_subdev_video_ops
tvp7002_video_ops = {
.enum_mbus_fmt = tvp7002_enum_mbus_fmt,
};
+/* media pad related operation handlers */
+static const struct v4l2_subdev_pad_ops tvp7002_pad_ops = {
+ .enum_mbus_code = tvp7002_enum_mbus_code,
+ .get_fmt = tvp7002_get_pad_format,
+ .set_fmt =
[PATCH 1/2] media: add support for decoder subdevs along with sensor and others
From: Manjunath Hadli
A lot of SOCs including Texas Instruments Davinci family mainly use
video decoders as input devices. Here the initial subdevice node
from where the input really comes is this decoder, for which support
is needed as part of the Media Controller infrastructure. This patch
adds an additional flag to include the decoders along with others,
such as the sensor and lens.
Signed-off-by: Manjunath Hadli
Signed-off-by: Lad, Prabhakar
---
include/uapi/linux/media.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 0ef8833..fa44ed9 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -56,6 +56,7 @@ struct media_device_info {
#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR (MEDIA_ENT_T_V4L2_SUBDEV + 1)
#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH (MEDIA_ENT_T_V4L2_SUBDEV + 2)
#define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV + 3)
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER(MEDIA_ENT_T_V4L2_SUBDEV + 4)
#define MEDIA_ENT_FL_DEFAULT (1 << 0)
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] TVP7002 add support for media controller based usag
From: Lad, Prabhakar The first patch adds a entry MEDIA_ENT_T_V4L2_SUBDEV_DECODER for decoders and second patch adds media controller support for tvp7002 decoder. Manjunath Hadli (2): media: add support for decoder subdevs along with sensor and others media: tvp7002: enable TVP7002 decoder for media controller based usage drivers/media/i2c/tvp7002.c | 132 +- include/media/tvp7002.h |2 + include/uapi/linux/media.h |1 + 3 files changed, 131 insertions(+), 4 deletions(-) -- 1.7.4.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: [GIT PULL] uprobes: pre-filtering
* Oleg Nesterov [2013-01-24 18:06:12]: > On 01/24, Ingo Molnar wrote: > > > > * Oleg Nesterov wrote: > > > > > Unfortunately, currently there is no in-kernel user of > > > pre-filtering. > > > > > > I'll try to implement the pid-base filtering at least for > > > tracing/uprobe_events, but this needs a time. Not only I am > > > not familiar with this code, I am not sure how this interface > > > should actually look. And I agree, perf should be able to use > > > it somehow, perhaps at least to allow to probe a single > > > task/mm. > > > > Would be nice to get something minimal/simple going, so that it > > can be tested, etc. > > Heh, I understand. > > I do not see anything simple to implement... I'll try to think. > Srikar, do you have any idea? > > All I can say right now: I'll send you the patches when I have them ;) > Can't promise this will be soon. > > _Perhaps_, as a first step, we can simply change create_trace_uprobe() > so that it would be possible to specify list-of-pids at creation time... > Not sure this actually makes sense. > [ Adding Masami and Steven since they have other ideas / inputs ] I can see two not-so-easy alternatives Reuse the event's post filtering meta data and convert it to a prefiltering handler. Convertion looks very tricky probe_event_enable() seems to be the right place to do this. tu->call.filter would have the post filtering data utc->filter needs to be set to the pre-filtering handler. The other alternative is to extend the current abi and pass the prefilter option. Should we extend the abi for userspace tracing is obviously debatable. > Oleg. > -- Thanks and Regards Srikar Dronamraju -- 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/4] USB: HID: SRW-S1 Add support for LEDs
From: simon
This patch to the SRW-S1 driver adds support for the LED RPM
meter on the front of the device. The LEDs are controlled via
/sys/class/leds interface, with an individual control for each
of the 15 LEDs.
Signed-off-by: Simon Wood
tested-by: John Murphy
---
Documentation/ABI/testing/sysfs-driver-hid-srws1 | 20 +++
drivers/hid/hid-srws1.c | 199 ++
2 files changed, 219 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-srws1
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-srws1
b/Documentation/ABI/testing/sysfs-driver-hid-srws1
new file mode 100644
index 000..c27b34d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-srws1
@@ -0,0 +1,20 @@
+What: /sys/class/leds/SRWS1RPM1
+What: /sys/class/leds/SRWS1RPM2
+What: /sys/class/leds/SRWS1RPM3
+What: /sys/class/leds/SRWS1RPM4
+What: /sys/class/leds/SRWS1RPM5
+What: /sys/class/leds/SRWS1RPM6
+What: /sys/class/leds/SRWS1RPM7
+What: /sys/class/leds/SRWS1RPM8
+What: /sys/class/leds/SRWS1RPM9
+What: /sys/class/leds/SRWS1RPM10
+What: /sys/class/leds/SRWS1RPM11
+What: /sys/class/leds/SRWS1RPM12
+What: /sys/class/leds/SRWS1RPM13
+What: /sys/class/leds/SRWS1RPM14
+What: /sys/class/leds/SRWS1RPM15
+Date: Jan 2013
+KernelVersion: 3.9
+Contact: Simon Wood
+Description: Provides a control for turning on/off the LEDs which form
+ an RPM meter on the front of the controller
diff --git a/drivers/hid/hid-srws1.c b/drivers/hid/hid-srws1.c
index 4d8a86b..6005b84 100644
--- a/drivers/hid/hid-srws1.c
+++ b/drivers/hid/hid-srws1.c
@@ -12,11 +12,21 @@
*/
#include
+#include
#include
#include
+#include "usbhid/usbhid.h"
#include "hid-ids.h"
+#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#define SRWS1_NUMBER_LEDS 15
+struct srws1_data {
+ __u16 led_state;
+ struct led_classdev *led[SRWS1_NUMBER_LEDS];
+};
+#endif
+
/* Fixed report descriptor for Steelseries SRW-S1 wheel controller
*
* The original descriptor hides the sensitivity and assists dials
@@ -97,6 +107,191 @@ static __u8 srws1_rdesc_fixed[] = {
0xC0/* End Collection */
};
+#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+static void srws1_set_leds(struct hid_device *hdev, __u16 leds)
+{
+ struct list_head *report_list =
>report_enum[HID_OUTPUT_REPORT].report_list;
+ struct hid_report *report = list_entry(report_list->next, struct
hid_report, list);
+ __s32 *value = report->field[0]->value;
+
+ value[0] = 0x40;
+ value[1] = leds;
+ value[2] = leds >> 8;
+ value[3] = 0x00;
+ value[4] = 0x00;
+ value[5] = 0x00;
+ value[6] = 0x00;
+ value[7] = 0x00;
+ value[8] = 0x00;
+ value[9] = 0x00;
+ value[10] = 0x00;
+ value[11] = 0x00;
+ value[12] = 0x00;
+ value[13] = 0x00;
+ value[14] = 0x00;
+ value[15] = 0x00;
+
+ usbhid_submit_report(hdev, report, USB_DIR_OUT);
+
+ /* Note: LED change does not show on device until the device is
read/polled */
+}
+
+static void srws1_led_set_brightness(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct device *dev = led_cdev->dev->parent;
+ struct hid_device *hid = container_of(dev, struct hid_device, dev);
+ struct srws1_data *drv_data = hid_get_drvdata(hid);
+ int i, state = 0;
+
+ if (!drv_data) {
+ hid_err(hid, "Device data not found.");
+ return;
+ }
+
+ for (i = 0; i < SRWS1_NUMBER_LEDS; i++) {
+ if (led_cdev != drv_data->led[i])
+ continue;
+
+ state = (drv_data->led_state >> i) & 1;
+ if (value == LED_OFF && state) {
+ drv_data->led_state &= ~(1 << i);
+ srws1_set_leds(hid, drv_data->led_state);
+ } else if (value != LED_OFF && !state) {
+ drv_data->led_state |= 1 << i;
+ srws1_set_leds(hid, drv_data->led_state);
+ }
+ break;
+ }
+}
+
+static enum led_brightness srws1_led_get_brightness(struct led_classdev
*led_cdev)
+{
+ struct device *dev = led_cdev->dev->parent;
+ struct hid_device *hid = container_of(dev, struct hid_device, dev);
+ struct srws1_data *drv_data;
+ int i, value = 0;
+
+ drv_data = hid_get_drvdata(hid);
+
+ if (!drv_data) {
+ hid_err(hid, "Device data not found.");
+ return LED_OFF;
+ }
+
+ for (i = 0; i < SRWS1_NUMBER_LEDS; i++)
+ if (led_cdev == drv_data->led[i]) {
+ value =
[PATCH 2/4] USB: HID: SRW-S1 Add support for dials
From: simon
This patch to the SRW-S1 driver re-writes the HID descriptor
to insert a section for the 3 dials on the device, previously
these were contained within a 'Manufacturer Specific' usage
page.
Signed-off-by: Simon Wood
tested-by: John Murphy
---
drivers/hid/hid-srws1.c | 86 ---
1 file changed, 82 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-srws1.c b/drivers/hid/hid-srws1.c
index 7776d74..4d8a86b 100644
--- a/drivers/hid/hid-srws1.c
+++ b/drivers/hid/hid-srws1.c
@@ -17,16 +17,94 @@
#include "hid-ids.h"
+/* Fixed report descriptor for Steelseries SRW-S1 wheel controller
+ *
+ * The original descriptor hides the sensitivity and assists dials
+ * a custom vendor usage page. This inserts a patch to make them
+ * appear in the 'Generic Desktop' usage.
+ */
+
+static __u8 srws1_rdesc_fixed[] = {
+0x05, 0x01, /* Usage Page (Desktop)*/
+0x09, 0x08, /* Usage (MultiAxis), Changed */
+0xA1, 0x01, /* Collection (Application), */
+0xA1, 0x02, /* Collection (Logical), */
+0x95, 0x01, /* Report Count (1), */
+0x05, 0x01, /* Changed Usage Page (Desktop), */
+0x09, 0x30, /* Changed Usage (X), */
+0x16, 0xF8, 0xF8, /* Logical Minimum (-1800),*/
+0x26, 0x08, 0x07, /* Logical Maximum (1800), */
+0x65, 0x14, /* Unit (Degrees), */
+0x55, 0x0F, /* Unit Exponent (15), */
+0x75, 0x10, /* Report Size (16), */
+0x81, 0x02, /* Input (Variable), */
+0x09, 0x31, /* Changed Usage (Y), */
+0x15, 0x00, /* Logical Minimum (0),*/
+0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
+0x75, 0x0C, /* Report Size (12), */
+0x81, 0x02, /* Input (Variable), */
+0x09, 0x32, /* Changed Usage (Z), */
+0x15, 0x00, /* Logical Minimum (0),*/
+0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
+0x75, 0x0C, /* Report Size (12), */
+0x81, 0x02, /* Input (Variable), */
+0x05, 0x01, /* Usage Page (Desktop), */
+0x09, 0x39, /* Usage (Hat Switch), */
+0x25, 0x07, /* Logical Maximum (7),*/
+0x35, 0x00, /* Physical Minimum (0), */
+0x46, 0x3B, 0x01, /* Physical Maximum (315), */
+0x65, 0x14, /* Unit (Degrees), */
+0x75, 0x04, /* Report Size (4),*/
+0x95, 0x01, /* Report Count (1), */
+0x81, 0x02, /* Input (Variable), */
+0x25, 0x01, /* Logical Maximum (1),*/
+0x45, 0x01, /* Physical Maximum (1), */
+0x65, 0x00, /* Unit, */
+0x75, 0x01, /* Report Size (1),*/
+0x95, 0x03, /* Report Count (3), */
+0x81, 0x01, /* Input (Constant), */
+0x05, 0x09, /* Usage Page (Button),*/
+0x19, 0x01, /* Usage Minimum (01h),*/
+0x29, 0x11, /* Usage Maximum (11h),*/
+0x95, 0x11, /* Report Count (17), */
+0x81, 0x02, /* Input (Variable), */
+/* Dial patch starts here */
+0x05, 0x01, /* Usage Page (Desktop), */
+0x09, 0x33, /* Usage (RX), */
+0x75, 0x04, /* Report Size (4),*/
+0x95, 0x02, /* Report Count (2), */
+0x15, 0x00, /* Logical Minimum (0),*/
+0x25, 0x0b, /* Logical Maximum (b),*/
+0x81, 0x02, /* Input (Variable), */
+0x09, 0x35, /* Usage (RZ), */
+0x75, 0x04, /* Report Size (4),*/
+0x95, 0x01, /* Report Count (1), */
+0x25, 0x03, /* Logical Maximum (3),*/
+0x81, 0x02, /* Input (Variable), */
+/* Dial patch ends here */
+0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+0x09, 0x01, /* Usage (01h),*/
+0x75, 0x04, /* Changed Report Size (4),*/
+0x95, 0x0D, /* Changed Report Count (13), */
+0x81, 0x02, /* Input (Variable), */
+0xC0, /* End Collection, */
+0xA1, 0x02, /* Collection (Logical), */
+0x09, 0x02,
[PATCH 4/4] USB: HID: SRW-S1 Add support controlling all LEDs simultaneously
From: simon
This patch to the SRW-S1 driver adds the ability to control all
LEDs simultaneously as testing showed that it was slow (noticably!!)
when seting or clearing all the LEDs in turn.
It adds a 'RPMALL' LED, whose behavoir is asserted to all the LEDs in
the bar graph, individual LEDs can subsequently be turned on/off
individually.
Signed-off-by: Simon Wood
tested-by: John Murphy
---
Documentation/ABI/testing/sysfs-driver-hid-srws1 |1 +
drivers/hid/hid-srws1.c | 67 --
2 files changed, 63 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-srws1
b/Documentation/ABI/testing/sysfs-driver-hid-srws1
index c27b34d..d0eba70 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-srws1
+++ b/Documentation/ABI/testing/sysfs-driver-hid-srws1
@@ -13,6 +13,7 @@ What: /sys/class/leds/SRWS1RPM12
What: /sys/class/leds/SRWS1RPM13
What: /sys/class/leds/SRWS1RPM14
What: /sys/class/leds/SRWS1RPM15
+What: /sys/class/leds/SRWS1RPMALL
Date: Jan 2013
KernelVersion: 3.9
Contact: Simon Wood
diff --git a/drivers/hid/hid-srws1.c b/drivers/hid/hid-srws1.c
index 6005b84..2604e4e 100644
--- a/drivers/hid/hid-srws1.c
+++ b/drivers/hid/hid-srws1.c
@@ -23,7 +23,7 @@
#define SRWS1_NUMBER_LEDS 15
struct srws1_data {
__u16 led_state;
- struct led_classdev *led[SRWS1_NUMBER_LEDS];
+ struct led_classdev *led[SRWS1_NUMBER_LEDS + 1]; /* including 'ALL' led
*/
};
#endif
@@ -136,6 +136,42 @@ static void srws1_set_leds(struct hid_device *hdev, __u16
leds)
/* Note: LED change does not show on device until the device is
read/polled */
}
+static void srws1_led_all_set_brightness(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct device *dev = led_cdev->dev->parent;
+ struct hid_device *hid = container_of(dev, struct hid_device, dev);
+ struct srws1_data *drv_data = hid_get_drvdata(hid);
+
+ if (!drv_data) {
+ hid_err(hid, "Device data not found.");
+ return;
+ }
+
+ if (value == LED_OFF)
+ drv_data->led_state = 0;
+ else
+ drv_data->led_state = (1 << (SRWS1_NUMBER_LEDS + 1)) - 1;
+
+ srws1_set_leds(hid, drv_data->led_state);
+}
+
+static enum led_brightness srws1_led_all_get_brightness(struct led_classdev
*led_cdev)
+{
+ struct device *dev = led_cdev->dev->parent;
+ struct hid_device *hid = container_of(dev, struct hid_device, dev);
+ struct srws1_data *drv_data;
+
+ drv_data = hid_get_drvdata(hid);
+
+ if (!drv_data) {
+ hid_err(hid, "Device data not found.");
+ return LED_OFF;
+ }
+
+ return (drv_data->led_state >> SRWS1_NUMBER_LEDS) ? LED_FULL : LED_OFF;
+}
+
static void srws1_led_set_brightness(struct led_classdev *led_cdev,
enum led_brightness value)
{
@@ -219,13 +255,34 @@ static int srws1_probe(struct hid_device *hdev,
/* register led subsystem */
drv_data->led_state = 0;
- for (i = 0; i < SRWS1_NUMBER_LEDS; i++)
+ for (i = 0; i < SRWS1_NUMBER_LEDS + 1; i++)
drv_data->led[i] = NULL;
srws1_set_leds(hdev, 0);
- name_sz = strlen(hdev->uniq) + 15;
+ name_sz = strlen(hdev->uniq) + 16;
+
+ /* 'ALL', for setting all LEDs simultaneously */
+ led = kzalloc(sizeof(struct led_classdev)+name_sz, GFP_KERNEL);
+ if (!led) {
+ hid_err(hdev, "can't allocate memory for LED ALL\n");
+ goto err_led;
+ }
+
+ name = (void *)([1]);
+ snprintf(name, name_sz, "SRWS1::%s::RPMALL", hdev->uniq);
+ led->name = name;
+ led->brightness = 0;
+ led->max_brightness = 1;
+ led->brightness_get = srws1_led_all_get_brightness;
+ led->brightness_set = srws1_led_all_set_brightness;
+
+ drv_data->led[SRWS1_NUMBER_LEDS] = led;
+ ret = led_classdev_register(>dev, led);
+ if (ret)
+ goto err_led;
+ /* Each individual LED */
for (i = 0; i < SRWS1_NUMBER_LEDS; i++) {
led = kzalloc(sizeof(struct led_classdev)+name_sz, GFP_KERNEL);
if (!led) {
@@ -248,7 +305,7 @@ static int srws1_probe(struct hid_device *hdev,
hid_err(hdev, "failed to register LED %d. Aborting.\n",
i);
err_led:
/* Deregister all LEDs (if any) */
- for (i = 0; i < SRWS1_NUMBER_LEDS; i++) {
+ for (i = 0; i < SRWS1_NUMBER_LEDS + 1; i++) {
led = drv_data->led[i];
drv_data->led[i] = NULL;
if (!led)
@@ -275,7 +332,7 @@ static void srws1_remove(struct hid_device *hdev)
if (drv_data) {
/* Deregister LEDs (if any) */
[PATCH 1/4] USB: HID: SRW-S1 Gaming Wheel Driver
From: simon
Add support the SRW-S1 by patching HID descriptor to read axis
as Generic Desktop X, Y and Z (rather than Usage page being
'Simulation').
Signed-off-by: Simon Wood
tested-by: John Murphy
---
drivers/hid/Kconfig |6 +
drivers/hid/Makefile|1 +
drivers/hid/hid-core.c |1 +
drivers/hid/hid-ids.h |3 +++
drivers/hid/hid-srws1.c | 58 +++
5 files changed, 69 insertions(+)
create mode 100644 drivers/hid/hid-srws1.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index e7d6a13..3c98517 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -596,6 +596,12 @@ config HID_SPEEDLINK
---help---
Support for Speedlink Vicious and Divine Cezanne mouse.
+config HID_SRWS1
+ tristate "Steelseries SRW-S1 steering wheel support"
+ depends on USB_HID
+ ---help---
+ Support for Steelseries SRW-S1 steering wheel
+
config HID_SUNPLUS
tristate "Sunplus wireless desktop"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index b622157..d3102e2 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_HID_SAMSUNG) += hid-samsung.o
obj-$(CONFIG_HID_SMARTJOYPLUS) += hid-sjoy.o
obj-$(CONFIG_HID_SONY) += hid-sony.o
obj-$(CONFIG_HID_SPEEDLINK)+= hid-speedlink.o
+obj-$(CONFIG_HID_SRWS1)+= hid-srws1.o
obj-$(CONFIG_HID_SUNPLUS) += hid-sunplus.o
obj-$(CONFIG_HID_GREENASIA)+= hid-gaff.o
obj-$(CONFIG_HID_THRUSTMASTER) += hid-tmff.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index eb2ee11..65cda7f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1697,6 +1697,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE)
},
+ { HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES,
USB_DEVICE_ID_STEELSERIES_SRWS1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4dfa605..f5976f3 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -723,6 +723,9 @@
#define USB_VENDOR_ID_STANTUM_SITRONIX 0x1403
#define USB_DEVICE_ID_MTP_SITRONIX 0x5001
+#define USB_VENDOR_ID_STEELSERIES 0x1038
+#define USB_DEVICE_ID_STEELSERIES_SRWS10x1410
+
#define USB_VENDOR_ID_SUN 0x0430
#define USB_DEVICE_ID_RARITAN_KVM_DONGLE 0xcdab
diff --git a/drivers/hid/hid-srws1.c b/drivers/hid/hid-srws1.c
new file mode 100644
index 000..7776d74
--- /dev/null
+++ b/drivers/hid/hid-srws1.c
@@ -0,0 +1,58 @@
+/*
+ * HID driver for Steelseries SRW-S1
+ *
+ * Copyright (c) 2013 Simon Wood
+ */
+
+/*
+ * 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.
+ */
+
+#include
+#include
+#include
+
+#include "hid-ids.h"
+
+static __u8 *srws1_report_fixup(struct hid_device *hdev, __u8 *rdesc,
+ unsigned int *rsize)
+{
+ if (*rsize >= 115 && rdesc[11] == 0x02 && rdesc[13] == 0xc8
+ && rdesc[29] == 0xbb && rdesc[40] == 0xc5) {
+ hid_info(hdev, "Fixing up Steelseries SRW-S1 report
descriptor\n");
+ rdesc[11] = 0x01;
+ rdesc[13] = 0x30;
+ rdesc[29] = 0x31;
+ rdesc[40] = 0x32;
+ }
+ return rdesc;
+}
+
+static const struct hid_device_id srws1_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES,
USB_DEVICE_ID_STEELSERIES_SRWS1) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, srws1_devices);
+
+static struct hid_driver srws1_driver = {
+ .name = "srws1",
+ .id_table = srws1_devices,
+ .report_fixup = srws1_report_fixup
+};
+
+static int __init srws1_init(void)
+{
+ return hid_register_driver(_driver);
+}
+
+static void __exit srws1_exit(void)
+{
+ hid_unregister_driver(_driver);
+}
+
+module_init(srws1_init);
+module_exit(srws1_exit);
+MODULE_LICENSE("GPL");
--
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 V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 02:12 PM, Jason Wang wrote:
> On 01/25/2013 01:40 PM, Wanlong Gao wrote:
>> On 01/25/2013 01:13 PM, Jason Wang wrote:
>>> On 01/25/2013 12:20 PM, Wanlong Gao wrote:
On 01/25/2013 11:28 AM, Jason Wang wrote:
> On 01/21/2013 07:25 PM, Wanlong Gao wrote:
>> Split out the clean affinity function to virtnet_clean_affinity().
>>
>> Cc: Rusty Russell
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc: Eric Dumazet
>> Cc: virtualizat...@lists.linux-foundation.org
>> Cc: net...@vger.kernel.org
>> Signed-off-by: Wanlong Gao
>> ---
>> V5->V6: NEW
>>
>> drivers/net/virtio_net.c | 67
>> +++-
>> 1 file changed, 38 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 70cd957..1a35a8c 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
>> net_device *dev, u16 vid)
>> return 0;
>> }
>>
>> -static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
>> +static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
>> {
>> int i;
>> int cpu;
>>
>> -/* In multiqueue mode, when the number of cpu is equal to the
>> number of
>> - * queue pairs, we let the queue pairs to be private to one cpu
>> by
>> - * setting the affinity hint to eliminate the contention.
>> - */
>> -if ((vi->curr_queue_pairs == 1 ||
>> - vi->max_queue_pairs != num_online_cpus()) && set) {
>> -if (vi->affinity_hint_set)
>> -set = false;
>> -else
>> -return;
>> -}
>> -
>> -if (set) {
>> -i = 0;
>> -for_each_online_cpu(cpu) {
>> -virtqueue_/set_affinity(vi->rq[i].vq, cpu);
>> -virtqueue_set_affinity(vi->sq[i].vq, cpu);
>> -*per_cpu_ptr(vi->vq_index, cpu) = i;
>> -i++;
>> -}
>> -
>> -vi->affinity_hint_set = true;
>> -} else {
>> -for(i = 0; i < vi->max_queue_pairs; i++) {
>> +if (vi->affinity_hint_set) {
>> +for (i = 0; i < vi->max_queue_pairs; i++) {
>> virtqueue_set_affinity(vi->rq[i].vq, -1);
>> virtqueue_set_affinity(vi->sq[i].vq, -1);
>> }
>>
>> i = 0;
>> -for_each_online_cpu(cpu)
>> +for_each_online_cpu(cpu) {
>> +if (cpu == hcpu)
>> +continue;
>> *per_cpu_ptr(vi->vq_index, cpu) =
>> ++i % vi->curr_queue_pairs;
>> +}
>>
> Some questions here:
>
> - Did we need reset the affinity of the queue here like the this?
>
> virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
> virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
I think no, we are going to unset the affinity of all the set queues,
include hcpu.
> - Looks like we need also reset the percpu index when
> vi->affinity_hint_set is false.
Yes, follow this and the comment on [1/3].
> - Does this really need this reset? Consider we're going to reset the
> percpu in CPU_DEAD?
I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong queue
on the dying CPU.
>>> Didn't understand this. What does 'wrong queue' here mean? Looks like
>>> you didn't change the preferable queue of the dying CPU and just change
>>> all others.
>> How about setting the vq index to -1 on hcpu when doing DOWN_PREPARE?
>> So that let it select txq to 0 when the CPU is dying.
>
> Looks safe, so look like what you're going to solve here is the the race
> between cpu hotplug and virtnet_set_channels(). A possible better
> solution is to serialize them by protecting virtnet_set_queues() by
> get_online_cpus() also. After this, we can make sure the number of
> channels were not changed during cpu hotplug, and looks like there's no
> need to reset the preferable queues in DOWN_PREPARE.
>
> What's your opinion?
IMHO, serialize every time will take lock and may slow down this path,
but the hot unplug path will be more cold than it. So I prefer reset the
preferable queues in DOWN_PREPARE but not serialize them. Agree?
Thanks,
Wanlong Gao
>
> Thanks
>>
>> Thanks,
>> Wanlong Gao
>>
Thanks,
Wanlong Gao
> Thanks
>>
[patch 1/2] video/kyro: delete some dead code
_OLDCODE is never defined. Delete it.
Signed-off-by: Dan Carpenter
diff --git a/drivers/video/kyro/STG4000OverlayDevice.c
b/drivers/video/kyro/STG4000OverlayDevice.c
index 0aeeaa1..84b6ea8 100644
--- a/drivers/video/kyro/STG4000OverlayDevice.c
+++ b/drivers/video/kyro/STG4000OverlayDevice.c
@@ -430,10 +430,7 @@ int SetOverlayViewPort(volatile STG4000REG __iomem
*pSTGReg,
*/
ulSrc = srcDest.ulSrcX2 - srcDest.ulSrcX1;
ulDest = srcDest.lDstX2 - srcDest.lDstX1;
-#ifdef _OLDCODE
- ulLeft = srcDest.ulDstX1;
- ulRight = srcDest.ulDstX2;
-#else
+
if (srcDest.ulDstX1 > 2) {
ulLeft = srcDest.ulDstX1 + 2;
ulRight = srcDest.ulDstX2 + 1;
@@ -441,7 +438,7 @@ int SetOverlayViewPort(volatile STG4000REG __iomem *pSTGReg,
ulLeft = srcDest.ulDstX1;
ulRight = srcDest.ulDstX2 + 1;
}
-#endif
+
/* first work out the position we are to display as offset from the
source of the buffer */
bResult = 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 V1 3/3] Xen processor driver
Agree, with minor comments below. Konrad Rzeszutek Wilk wrote: >> >> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig >> index 2dc7022..ca2535a 100644 >> --- a/drivers/xen/Kconfig >> +++ b/drivers/xen/Kconfig >> @@ -202,6 +202,18 @@ config XEN_ACPI_HOTPLUG_MEMORY >>to hot-add memory at runtime (the hot-added memory cannot be >>removed until machine stop), select Y/M here, otherwise select N. >> >> +config XEN_PROCESSOR > > I think the name should be XEN_ACPI_PROCESSOR but then the > xen-acpi-processor gets in the way. Hm, perhaps this should be then > called xen-acpi-cpu-hotplug.c ? > > Would that work? > > Or xen-acpi-cpu.c? > > So then it is called 'XEN_ACPI_CPU' ? So let's use xen-acpi-cpuhoplut.c and XEN_ACPI_HOTPLUG_CPU, compared with xen memory hotplug xen-acpi-memhotplug.c and XEN_ACPI_HOTPLUG_MEMORY > > >> +tristate "Xen processor driver" >> +depends on XEN_STUB && ACPI > > Is there anytime a scenario where the user might compile a kernel > without DOM0 support, but with Xen_stub && ACPI? Hmm, let's relax xen-stub.c by 'depends on XEN' and for xen cpu/mem hotplug add 'depends on XEN_DOM0' Thanks, Jinsong-- 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 V1 1/3] Xen stub driver for CPU hotplug
Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 15, 2013 at 12:30:19PM +, Liu, Jinsong wrote:
>>> From 110b4ef3b8ebefeaf68832dd8ef8aa916a782e89 Mon Sep 17 00:00:00
>>> 2001
>> From: Liu Jinsong
>> Date: Mon, 14 Jan 2013 15:19:30 +0800
>> Subject: [PATCH 1/3] Xen stub driver for CPU hotplug
>>
>> Add Xen stub driver for CPU hotplug, early occupy to block native,
>> will be replaced later by real Xen processor driver module.
>>
>> Signed-off-by: Liu Jinsong
>> ---
>> drivers/xen/xen-stub.c | 34 --
>> include/xen/acpi.h |6 ++
>> 2 files changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/xen-stub.c b/drivers/xen/xen-stub.c
>> index 01a49e3..681e9cc 100644
>> --- a/drivers/xen/xen-stub.c
>> +++ b/drivers/xen/xen-stub.c
>> @@ -28,12 +28,13 @@
>> #include
>> #include
>>
>> +
>> +#ifdef CONFIG_ACPI
>> +
>> /*
>> stub driver for Xen memory hotplug
>> */
>>
>> -#ifdef CONFIG_ACPI
>> -
>> static const struct acpi_device_id memory_device_ids[] = {
>> {ACPI_MEMORY_DEVICE_HID, 0},
>> {"", 0},
>> @@ -57,4 +58,33 @@ static int __init
>> xen_stub_memory_device_init(void) }
>> subsys_initcall(xen_stub_memory_device_init);
>>
>> +
>> +/*
>> +stub driver for Xen cpu hotplug
>> +*/
>> +
>> +static const struct acpi_device_id processor_device_ids[] = {
>> +{ACPI_PROCESSOR_OBJECT_HID, 0},
>> +{ACPI_PROCESSOR_DEVICE_HID, 0},
>> +{"", 0},
>> +};
>> +
>> +struct acpi_driver xen_stub_processor_driver = {
>> +/* same name as native processor driver to block native loaded */
>> +.name = "processor", + .class = ACPI_PROCESSOR_CLASS,
>> +.ids = processor_device_ids,
>> +};
>> +EXPORT_SYMBOL_GPL(xen_stub_processor_driver);
>
> Could you make this be
>
> xen_stub_processor_deinit() instead?
>
Updated, w/ 2 funcs EXPORT_SYMBOL_GPL to cpu hotplug module:
xen_stub_processor_init()
xen_stub_processor_exit()
Thanks,
Jinsong--
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] ARM: regulator: add tps6507x device tree data
Hi Mark, On Thu, Jan 24, 2013 at 17:30:51, Mark Brown wrote: > On Thu, Jan 24, 2013 at 04:25:19PM +0530, Vishwanathrao Badarkhe, Manish > wrote: > > > --- > > arch/arm/boot/dts/tps6507x.dtsi | 47 > > +++ > > Why are you putting this in arch/arm? > I too doubt that whether it should be in architecture specific folder, My code is in reference to below patch: arm/dts: regulator: Add tps65910 device tree data(d5d08e2e1672da627d7c9d34a9dc1089c653e23a) Could you please suggest me if it can be moved somewhere else? Regards, Manish -- 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/1] Drivers: scsi: storvsc: Initialize the sglist
On 01/25/2013 09:04 AM, K. Y. Srinivasan wrote:
> Properly initialize scatterlist before using it.
>
> Signed-off-by: K. Y. Srinivasan
> Cc: Stable
Reviewed-by: Wanlong Gao
> ---
> drivers/scsi/storvsc_drv.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 270b3cf..5ada1d0 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -467,6 +467,7 @@ static struct scatterlist *create_bounce_buffer(struct
> scatterlist *sgl,
> if (!bounce_sgl)
> return NULL;
>
> + sg_init_table(bounce_sgl, num_pages);
> for (i = 0; i < num_pages; i++) {
> page_buf = alloc_page(GFP_ATOMIC);
> if (!page_buf)
>
--
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 V8 00/13] MIPS: Add Loongson-3 based machines support
On 25/01/13 01:15, 陈华才 wrote: > ok, I'll prepare v9 of this seris in these days. >> Please dont send v9 read my mail and compile / runtime test the tree please only patch 3 needs to be reworked and an update for the "MIPS: Loongson 3: Add HT-linked PCI support." needs to e made John >>> >>> Huacai Chen(13): >>>MIPS: Loongson: Add basic Loongson-3 definition. >>>MIPS: Loongson: Add basic Loongson-3 CPU support. >>>MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature. >>>MIPS: Loongson 3: Add Lemote-3A machtypes definition. >>>MIPS: Loongson: Add UEFI-like firmware interface support. >>>MIPS: Loongson 3: Add HT-linked PCI support. >>>MIPS: Loongson 3: Add IRQ init and dispatch support. >>>MIPS: Loongson 3: Add serial port support. >>>MIPS: Loongson: Add swiotlb to support big memory (>4GB). >>>MIPS: Loongson: Add Loongson-3 Kconfig options. >>>MIPS: Loongson 3: Add Loongson-3 SMP support. >>>MIPS: Loongson 3: Add CPU hotplug support. >>>MIPS: Loongson: Add a Loongson-3 default config file. >>> >>> Signed-off-by: Huacai Chen >>> Signed-off-by: Hongliang Tao >>> Signed-off-by: Hua Yan >>> --- >> >> Hi, >> >> I have added all patches apart from 3/13 to my queue. >> >> I believe "MIPS: Loongson: Introduce and use cpu_has_coherent_cache >> feature." should e rewritten in a saner way. >> >> Please compile and runtime test the tree before I send it to Ralf >> --> >> http://git.linux-mips.org/?p=john/linux-john.git;a=shortlog;h=refs/heads/mips-next-3.9 >> >> I cleaned up a few minor whitespace errors while merging. >> >> http://patchwork.linux-mips.org/patch/4547/ has a few comments. Please >> prepare a patch asap to address those so i can fold it into the series. >> >> John >> > > -- 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] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
On 1/21/2013 11:59 AM, Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
> file to use emac clock.
>
> Signed-off-by: Lad, Prabhakar
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
> Cc: net...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: Sekhar Nori
> Cc: Heiko Schocher
> ---
> arch/arm/mach-davinci/da8xx-dt.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
> b/arch/arm/mach-davinci/da8xx-dt.c
> index 37c27af..d548a38 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -37,11 +37,18 @@ static void __init da8xx_init_irq(void)
> of_irq_init(da8xx_irq_match);
> }
>
> +struct of_dev_auxdata da850_evm_auxdata_lookup[] __initdata = {
This is specific to da850 and not da850_evm so it should be named so.
You can call it da8xx_auxdata keeping with the file naming.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: davinci: da850: add DT node for eth0.
Prabhakar,
On 1/21/2013 11:59 AM, Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> Add eth0 device tree node information to da850 by
> providing interrupt details and local mac address of eth0.
>
> Signed-off-by: Lad, Prabhakar
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
> Cc: net...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: Sekhar Nori
> Cc: Heiko Schocher
> ---
> arch/arm/boot/dts/da850-evm.dts |3 +++
> arch/arm/boot/dts/da850.dtsi| 15 +++
Can you rebase this to apply to v3.9/dt branch of my tree?
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 37dc5a3..a1d6e3e 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -24,5 +24,8 @@
> serial2: serial@1d0d000 {
> status = "okay";
> };
> + eth0: emac@1e2 {
> + status = "okay";
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 640ab75..309cc99 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -56,5 +56,20 @@
> interrupt-parent = <>;
> status = "disabled";
> };
> + eth0: emac@1e2 {
> + compatible = "ti,davinci-dm6467-emac";
> + reg = <0x22 0x4000>;
> + ti,davinci-ctrl-reg-offset = <0x3000>;
> + ti,davinci-ctrl-mod-reg-offset = <0x2000>;
> + ti,davinci-ctrl-ram-offset = <0>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <33
> + 34
> + 35
> + 36
> + >;
> + interrupt-parent = <>;
instead of setting interrupt-parent for each node, this can be done once
for soc and child nodes should inherit this property. This needs to be
fixed for existing serial nodes too.
Also, can you take care of pinmux too? we should not be relying on
u-boot to setup the pinmux for us.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: davinci: da850: add RTC driver DT entries
Add RTC DT entries in da850 dts file.
Signed-off-by: Mrugesh Katepallewar
---
Applies on top of v3.8-rc4 of linus tree.
Tested on da850-evm device.
Test Procedure:
date [.]MM.DD-hh:mm[:ss]
hwclock -w
reset board and check system time.
:100644 100644 37dc5a3... b16efd4... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 640ab75... a8eb1b1... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts |3 +++
arch/arm/boot/dts/da850.dtsi|8
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..b16efd4 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -24,5 +24,8 @@
serial2: serial@1d0d000 {
status = "okay";
};
+ rtc@1c23000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 640ab75..a8eb1b1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,5 +56,13 @@
interrupt-parent = <>;
status = "disabled";
};
+ rtc@1c23000 {
+ compatible = "ti,da830-rtc";
+ reg = <0x23000 0x1000>;
+ interrupts = <19
+ 19>;
+ interrupt-parent = <>;
+ status = "disabled";
+ };
};
};
--
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: [PATCH 23/32] Generic dynamic per cpu refcounting
Tejun Heo writes: >> It also implements two stage shutdown, as we need it to tear down the >> percpu counts. Before dropping the initial refcount, you must call >> percpu_ref_kill(); this puts the refcount in "shutting down mode" and >> switches back to a single atomic refcount with the appropriate barriers >> (synchronize_rcu()). > > Maybe if we have tryget() which only succeeds if the counter is alive, > we can replace moulde refcnt with this? Rusty? Yes, it's similar (hence my previous interest), though module count is a bit weird. Like Tejun, I'd prefer to see it always alloc up-front, because it avoids the _noalloc variant (which is backwards: please hand gfp_t, so you don't hide the alloc) and heuristics. Cheers, Rusty. -- 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: Doubts about listen backlog and tcp_max_syn_backlog
On 01/24/2013 11:21 AM, Leandro Lucarella wrote: > On Thu, Jan 24, 2013 at 10:44:32AM -0800, Rick Jones wrote: >> On 01/24/2013 04:22 AM, Leandro Lucarella wrote: >>> On Wed, Jan 23, 2013 at 11:28:08AM -0800, Rick Jones wrote: > Then if syncookies are enabled, the time spent in connect() shouldn't be > bigger than 3 seconds even if SYNs are being "dropped" by listen, right? Do you mean if "ESTABLISHED" connections are dropped because the listen queue is full? I don't think I would put that as "SYNs being dropped by listen" - too easy to confuse that with an actual dropping of a SYN segment. >>> >>> I was just kind of quoting the name given by netstat: "SYNs to LISTEN >>> sockets dropped" (for kernel 3.0, I noticed newer kernels don't have >>> this stat anymore, or the name was changed). I still don't know if we >>> are talking about the same thing. >> [snip] >> I will sometimes be tripped-up by netstat's not showing a statistic >> with a zero value... Leandro, you should be able to do an nstat -z, it will print all counters even if zero. You should see something like so: ipv4]> nstat -z #kernel IpInReceives2135 0.0 IpInHdrErrors 0 0.0 IpInAddrErrors 2020.0 ... You might want to take a look at those (your pkts may not even be making it to tcp) and these in particular: TcpExtSyncookiesSent0 0.0 TcpExtSyncookiesRecv0 0.0 TcpExtSyncookiesFailed 0 0.0 TcpExtListenOverflows 0 0.0 TcpExtListenDrops 0 0.0 TcpExtTCPBacklogDrop0 0.0 TcpExtTCPMinTTLDrop 0 0.0 TcpExtTCPDeferAcceptDrop0 0.0 If you don't have nstat on that version for some reason, download the latest iproute pkg. Looking at the counter names is a lot more helpful and precise than the netstat converstion to human consumption. > Yes, I already did captures and we are definitely loosing packets > (including SYNs), but it looks like the amount of SYNs I'm loosing is > lower than the amount of long connect() times I observe. This is not > confirmed yet, I'm still investigating. Where did you narrow down the drop to? There are quite a few places in the networking stack we silently drop packets (such as the one pointed out earlier in this thread), although they should almost all be extremely low probability/NEVER type events. Do you want a patch to gap the most likely scenario? (I'll post that to netdev separately). thanks, Nivedita -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 01:40 PM, Wanlong Gao wrote:
> On 01/25/2013 01:13 PM, Jason Wang wrote:
>> On 01/25/2013 12:20 PM, Wanlong Gao wrote:
>>> On 01/25/2013 11:28 AM, Jason Wang wrote:
On 01/21/2013 07:25 PM, Wanlong Gao wrote:
> Split out the clean affinity function to virtnet_clean_affinity().
>
> Cc: Rusty Russell
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Eric Dumazet
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Wanlong Gao
> ---
> V5->V6: NEW
>
> drivers/net/virtio_net.c | 67
> +++-
> 1 file changed, 38 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 70cd957..1a35a8c 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
> net_device *dev, u16 vid)
> return 0;
> }
>
> -static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
> +static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
> {
> int i;
> int cpu;
>
> - /* In multiqueue mode, when the number of cpu is equal to the number of
> - * queue pairs, we let the queue pairs to be private to one cpu by
> - * setting the affinity hint to eliminate the contention.
> - */
> - if ((vi->curr_queue_pairs == 1 ||
> - vi->max_queue_pairs != num_online_cpus()) && set) {
> - if (vi->affinity_hint_set)
> - set = false;
> - else
> - return;
> - }
> -
> - if (set) {
> - i = 0;
> - for_each_online_cpu(cpu) {
> - virtqueue_/set_affinity(vi->rq[i].vq, cpu);
> - virtqueue_set_affinity(vi->sq[i].vq, cpu);
> - *per_cpu_ptr(vi->vq_index, cpu) = i;
> - i++;
> - }
> -
> - vi->affinity_hint_set = true;
> - } else {
> - for(i = 0; i < vi->max_queue_pairs; i++) {
> + if (vi->affinity_hint_set) {
> + for (i = 0; i < vi->max_queue_pairs; i++) {
> virtqueue_set_affinity(vi->rq[i].vq, -1);
> virtqueue_set_affinity(vi->sq[i].vq, -1);
> }
>
> i = 0;
> - for_each_online_cpu(cpu)
> + for_each_online_cpu(cpu) {
> + if (cpu == hcpu)
> + continue;
> *per_cpu_ptr(vi->vq_index, cpu) =
> ++i % vi->curr_queue_pairs;
> + }
>
Some questions here:
- Did we need reset the affinity of the queue here like the this?
virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>>> I think no, we are going to unset the affinity of all the set queues,
>>> include hcpu.
>>>
- Looks like we need also reset the percpu index when
vi->affinity_hint_set is false.
>>> Yes, follow this and the comment on [1/3].
>>>
- Does this really need this reset? Consider we're going to reset the
percpu in CPU_DEAD?
>>> I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong queue
>>> on the dying CPU.
>> Didn't understand this. What does 'wrong queue' here mean? Looks like
>> you didn't change the preferable queue of the dying CPU and just change
>> all others.
> How about setting the vq index to -1 on hcpu when doing DOWN_PREPARE?
> So that let it select txq to 0 when the CPU is dying.
Looks safe, so look like what you're going to solve here is the the race
between cpu hotplug and virtnet_set_channels(). A possible better
solution is to serialize them by protecting virtnet_set_queues() by
get_online_cpus() also. After this, we can make sure the number of
channels were not changed during cpu hotplug, and looks like there's no
need to reset the preferable queues in DOWN_PREPARE.
What's your opinion?
Thanks
>
> Thanks,
> Wanlong Gao
>
>>> Thanks,
>>> Wanlong Gao
>>>
Thanks
> vi->affinity_hint_set = false;
> }
> }
>
> +static void virtnet_set_affinity(struct virtnet_info *vi)
> +{
> + int i;
> + int cpu;
> +
> + /* In multiqueue mode, when the number of cpu is equal to the number of
> + * queue pairs, we let the queue pairs to be private to one cpu by
> + * setting the affinity hint to eliminate the contention.
> + */
> + if (vi->curr_queue_pairs == 1 ||
> + vi->max_queue_pairs != num_online_cpus()) {
> + if (vi->affinity_hint_set)
> + virtnet_clean_affinity(vi, -1);
> + else
> + return;
> + }
> +
> + i = 0;
> +
Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
On Fri, Jan 25, 2013 at 10:06:01AM +1030, Rusty Russell wrote: > Kyle McMartin writes: > > After thinking about it a while, this seems like the best way to solve > > the problem, although it does still kind of offend my delicate > > sensibilities... > > You're far too polite. This patch was horrible, partial and ugly. > Yeah, fair enough. -- 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 3/4] MODSIGN: Add -s option to sign-file
David Howells writes: > Feel free to add: > > Acked-by: David Howells > > to your patches. Thanks, done and applied. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 01:13 PM, Jason Wang wrote:
> On 01/25/2013 12:20 PM, Wanlong Gao wrote:
>> On 01/25/2013 11:28 AM, Jason Wang wrote:
>>> On 01/21/2013 07:25 PM, Wanlong Gao wrote:
Split out the clean affinity function to virtnet_clean_affinity().
Cc: Rusty Russell
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Eric Dumazet
Cc: virtualizat...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Signed-off-by: Wanlong Gao
---
V5->V6: NEW
drivers/net/virtio_net.c | 67
+++-
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 70cd957..1a35a8c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
net_device *dev, u16 vid)
return 0;
}
-static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
+static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
{
int i;
int cpu;
- /* In multiqueue mode, when the number of cpu is equal to the number of
- * queue pairs, we let the queue pairs to be private to one cpu by
- * setting the affinity hint to eliminate the contention.
- */
- if ((vi->curr_queue_pairs == 1 ||
- vi->max_queue_pairs != num_online_cpus()) && set) {
- if (vi->affinity_hint_set)
- set = false;
- else
- return;
- }
-
- if (set) {
- i = 0;
- for_each_online_cpu(cpu) {
- virtqueue_/set_affinity(vi->rq[i].vq, cpu);
- virtqueue_set_affinity(vi->sq[i].vq, cpu);
- *per_cpu_ptr(vi->vq_index, cpu) = i;
- i++;
- }
-
- vi->affinity_hint_set = true;
- } else {
- for(i = 0; i < vi->max_queue_pairs; i++) {
+ if (vi->affinity_hint_set) {
+ for (i = 0; i < vi->max_queue_pairs; i++) {
virtqueue_set_affinity(vi->rq[i].vq, -1);
virtqueue_set_affinity(vi->sq[i].vq, -1);
}
i = 0;
- for_each_online_cpu(cpu)
+ for_each_online_cpu(cpu) {
+ if (cpu == hcpu)
+ continue;
*per_cpu_ptr(vi->vq_index, cpu) =
++i % vi->curr_queue_pairs;
+ }
>>> Some questions here:
>>>
>>> - Did we need reset the affinity of the queue here like the this?
>>>
>>> virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>>> virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>> I think no, we are going to unset the affinity of all the set queues,
>> include hcpu.
>>
>>> - Looks like we need also reset the percpu index when
>>> vi->affinity_hint_set is false.
>> Yes, follow this and the comment on [1/3].
>>
>>> - Does this really need this reset? Consider we're going to reset the
>>> percpu in CPU_DEAD?
>> I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong queue
>> on the dying CPU.
>
> Didn't understand this. What does 'wrong queue' here mean? Looks like
> you didn't change the preferable queue of the dying CPU and just change
> all others.
How about setting the vq index to -1 on hcpu when doing DOWN_PREPARE?
So that let it select txq to 0 when the CPU is dying.
Thanks,
Wanlong Gao
>>
>> Thanks,
>> Wanlong Gao
>>
>>> Thanks
vi->affinity_hint_set = false;
}
}
+static void virtnet_set_affinity(struct virtnet_info *vi)
+{
+ int i;
+ int cpu;
+
+ /* In multiqueue mode, when the number of cpu is equal to the number of
+ * queue pairs, we let the queue pairs to be private to one cpu by
+ * setting the affinity hint to eliminate the contention.
+ */
+ if (vi->curr_queue_pairs == 1 ||
+ vi->max_queue_pairs != num_online_cpus()) {
+ if (vi->affinity_hint_set)
+ virtnet_clean_affinity(vi, -1);
+ else
+ return;
+ }
+
+ i = 0;
+ for_each_online_cpu(cpu) {
+ virtqueue_set_affinity(vi->rq[i].vq, cpu);
+ virtqueue_set_affinity(vi->sq[i].vq, cpu);
+ *per_cpu_ptr(vi->vq_index, cpu) = i;
+ i++;
+ }
+
+ vi->affinity_hint_set = true;
+}
+
static void virtnet_get_ringparam(struct net_device *dev,
struct ethtool_ringparam *ring)
{
@@ -1105,7 +1114,7 @@ static int virtnet_set_channels(struct net_device
*dev,
[GIT PULL] Btrfs fixes (v2)
Hi Linus, My for-linus branch has our batch of btrfs fixes: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus It turns out that we had two crc bugs when running fsx-linux in a loop. Many thanks to Josef, Miao Xie, and Dave Sterba for nailing it all down. Miao also has a new OOM fix in this v2 pull as well. Ilya fixed a regression Liu Bo found in the balance ioctls for pausing and resuming a running balance across drives. Josef's orphan truncate patch fixes an obscure corruption we'd see during xfstests. Arne's patches address problems with subvolume quotas. If the user destroys quota groups incorrectly the FS will refuse to mount. The rest are smaller fixes and plugs for memory leaks. Miao Xie (8) commits (+76/-24): Btrfs: fix missing write access release in btrfs_ioctl_resize() (+1/-0) Btrfs: do not delete a subvolume which is in a R/O subvolume (+5/-5) Btrfs: Add ACCESS_ONCE() to transaction->abort accesses (+3/-2) Btrfs: fix wrong max device number for single profile (+1/-1) Btrfs: fix repeated delalloc work allocation (+41/-14) Btrfs: fix missed transaction->aborted check (+16/-0) Btrfs: fix resize a readonly device (+4/-2) Btrfs: disable qgroup id 0 (+5/-0) Ilya Dryomov (6) commits (+94/-32): Btrfs: reorder locks and sanity checks in btrfs_ioctl_defrag (+9/-8) Btrfs: fix "mutually exclusive op is running" error code (+4/-4) Btrfs: fix a regression in balance usage filter (+8/-1) Btrfs: bring back balance pause/resume logic (+71/-17) Btrfs: fix unlock order in btrfs_ioctl_rm_dev (+1/-1) Btrfs: fix unlock order in btrfs_ioctl_resize (+1/-1) Liu Bo (5) commits (+23/-7): Btrfs: fix a bug when llseek for delalloc bytes behind prealloc extents (+14/-6) Btrfs: use right range to find checksum for compressed extents (+5/-0) Btrfs: let allocation start from the right raid type (+1/-1) Btrfs: reset path lock state to zero (+2/-0) Btrfs: fix off-by-one in lseek (+1/-0) Josef Bacik (5) commits (+69/-29): Btrfs: do not allow logged extents to be merged or removed (+16/-3) Btrfs: add orphan before truncating pagecache (+38/-15) Btrfs: set flushing if we're limited flushing (+1/-1) Btrfs: put csums on the right ordered extent (+2/-2) Btrfs: fix panic when recovering tree log (+12/-8) Arne Jansen (2) commits (+19/-1): Btrfs: prevent qgroup destroy when there are still relations (+12/-1) Btrfs: ignore orphan qgroup relations (+7/-0) Zach Brown (1) commits (+1/-0): btrfs: fix btrfs_cont_expand() freeing IS_ERR em Lukas Czerner (1) commits (+1/-1): btrfs: get the device in write mode when deleting it Eric Sandeen (1) commits (+14/-3): btrfs: update timestamps on truncate() Tsutomu Itoh (1) commits (+3/-1): Btrfs: fix memory leak in name_cache_insert() Total: (30) commits (+300/-98) fs/btrfs/extent-tree.c | 6 +- fs/btrfs/extent_map.c | 13 - fs/btrfs/extent_map.h | 1 + fs/btrfs/file-item.c| 4 +- fs/btrfs/file.c | 10 +++- fs/btrfs/free-space-cache.c | 20 --- fs/btrfs/inode.c| 137 +--- fs/btrfs/ioctl.c| 129 ++--- fs/btrfs/qgroup.c | 20 ++- fs/btrfs/send.c | 4 +- fs/btrfs/super.c| 2 +- fs/btrfs/transaction.c | 19 +- fs/btrfs/tree-log.c | 10 +++- fs/btrfs/volumes.c | 23 ++-- 14 files changed, 300 insertions(+), 98 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote: > Added a new driver for the usb part of control module. This has an API > to power on the USB2 phy and an API to write to the mailbox depending on > whether MUSB has to act in host mode or in device mode. > > Writing to control module registers for doing the above task which was > previously done in omap glue and in omap-usb2 phy will be removed. > diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt > b/Documentation/devicetree/bindings/usb/usb-phy.txt This file seems to be specific to the TI USB PHYs, not all USB PHYs; shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match the compatible value it documents, giving ti,omap-usb2.txt? > add the address of control module dev conf register until a driver for > control module is added > > +Optional properties: > + - ctrl_module : phandle of the control module used by PHY driver to power on > + the PHY. DT property names generally use - not _ as the word separator. -- 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/
linux-next: Tree for Jan 25
Hi all, Changes since 20130124: New trees: ipsec and ipsec-next The powerpc tree still had a build failure. The sound-asoc tree still had its build failure so I used the version from next-20130122. The akpm tree lost its build failure and several patches that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 211 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (ba2ab41 Merge tag 'pm+acpi-for-3.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fixes/master (d287b87 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arm-current/fixes (210b184 Merge branch 'for-rmk/virt/hyp-boot/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into fixes) Merging m68k-current/for-linus (e7e29b4 m68k: Wire up finit_module) Merging powerpc-merge/merge (e6449c9 powerpc: Add missing NULL terminator to avoid boot panic on PPC40x) Merging sparc/master (04cef49 sparc: kernel/sbus.c: fix memory leakage) Merging net/master (5d0feaf r8169: remove the obsolete and incorrect AMD workaround) Merging ipsec/master (5d0feaf r8169: remove the obsolete and incorrect AMD workaround) Merging sound-current/for-linus (0712eea ALSA: hda - Add a fixup for Packard-Bell desktop with ALC880) Merging pci-current/for-linus (444ee9b PCI: remove depends on CONFIG_EXPERIMENTAL) Merging wireless/master (83f0c6d mwifiex: fix typo in PCIe adapter NULL check) Merging driver-core.current/driver-core-linus (7d1f9ae Linux 3.8-rc4) Merging tty.current/tty-linus (ba2ab41 Merge tag 'pm+acpi-for-3.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging usb.current/usb-linus (ba2ab41 Merge tag 'pm+acpi-for-3.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging staging.current/staging-linus (248152b Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging char-misc.current/char-misc-linus (a7e2ca1 Revert "drivers/misc/ti-st: remove gpio handling") Merging input-current/for-linus (9937c02 Input: wacom - fix wacom_set_report retry logic) Merging md-current/for-linus (a9add5d md/raid5: add blktrace calls) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device tree binding for ERA information.) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option) CONFLICT (content): Merge conflict in arch/x86/Kconfig Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value ch
Crash with 9fdb04c "async: replace list of active domains with global list of pending items"
Tejun, In next-20130124, I see a crash during boot on my ARM system unless I revert 9fdb04c "async: replace list of active domains with global list of pending items". This was reported t me by Venu (CC'd). The kernel log is below. Looking at that patch, I note that __async_schedule() does: > list_add_tail(>domain_list, >pending); > if (domain->registered) > list_add_tail(>global_list, _global_pending); ... whereas async_run_entry_fn() unconditionally undoes both those list_add_tail() calls, even if the second never executed and hence the list entry was never initialized: > list_del_init(>domain_list); > list_del_init(>global_list); Therefore, I think the fix is: diff --git a/kernel/async.c b/kernel/async.c index 6958000..3507d5a 100644 --- a/kernel/async.c +++ b/kernel/async.c @@ -137,7 +137,8 @@ static void async_run_entry_fn(struct work_struct *work) /* 2) remove self from the pending queues */ spin_lock_irqsave(_lock, flags); list_del_init(>domain_list); - list_del_init(>global_list); + if (entry->domain->registered) + list_del_init(>global_list); /* 3) free the entry */ kfree(entry); At least, that does prevent the crash I was seeing. > [1.209020] usbhid: USB HID core driver > [1.215662] usb 1-1: new high-speed USB device number 2 using tegra-ehci > [1.226634] Unable to handle kernel NULL pointer dereference at virtual > address 0004 > [1.234707] pgd = c0004000 > [1.237403] [0004] *pgd= > [1.240974] Internal error: Oops: 805 [#1] PREEMPT SMP ARM > [1.246444] Modules linked in: > [1.249495] CPU: 0Not tainted (3.8.0-rc4-00154-g9fdb04c #31) > [1.255579] PC is at async_run_entry_fn+0x94/0x188 > [1.260357] LR is at async_run_entry_fn+0x68/0x188 > [1.265135] pc : []lr : []psr: 6193 > [1.265135] sp : ee061ec0 ip : fp : c074a0cc > [1.276587] r10: r9 : ee2d2750 r8 : 6113 > [1.281796] r7 : ee2d2750 r6 : ee2d2740 r5 : c0749fc0 r4 : c074a5a8 > [1.288306] r3 : ee2d2748 r2 : r1 : r0 : ee2d2740 > [1.294817] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [1.302193] Control: 10c5387d Table: 404a DAC: 0015 > [1.307923] Process kworker/u:0 (pid: 6, stack limit = 0xee060238) > [1.314086] Stack: (0xee061ec0 to 0xee062000) > [1.318433] 1ec0: c0f8b18c c06e54e8 ee061efc c0052054 c06e54e8 ee039ec0 > c0749fc0 ee039ec0 > [1.326592] 1ee0: c0749fc0 ee06 ee04ae00 ee2d2750 c003d1c0 > c0749fc0 c003f8a4 > [1.334751] 1f00: ee2a6840 ee039ec0 c074a0cc ee06 > c074a0d4 ee039ed4 > [1.342910] 1f20: c06e54e8 677d46cf c06d9c00 c003fab4 ee039ec0 c0749fc0 > c06d9c00 c06d9c00 > [1.351070] 1f40: ee039ec0 ee053e74 ee061f6c ee039ec0 c003f940 > > [1.359229] 1f60: c0044578 dfbe67df bdfff7fd ee039ec0 > > [1.367389] 1f80: ee061f80 ee061f80 ee061f90 ee061f90 > ee053e74 c00444d0 > [1.375547] 1fa0: c000e5b8 > > [1.383707] 1fc0: > > [1.391866] 1fe0: 0013 > a5eaafdf feb77e37 > [1.400039] [] (async_run_entry_fn+0x94/0x188) from [] > (process_one_work+0x128/0x400) > [1.409592] [] (process_one_work+0x128/0x400) from [] > (worker_thread+0x174/0x4a8) > [1.418800] [] (worker_thread+0x174/0x4a8) from [] > (kthread+0xa8/0xb4) > [1.427057] [] (kthread+0xa8/0xb4) from [] > (ret_from_fork+0x14/0x3c) > [1.435131] Code: e596200c e5961008 e5076010 e5866004 (e5812004) > [1.441224] ---[ end trace cd37b837c57b2b30 ]--- > [1.445830] note: kworker/u:0[6] exited with preempt_count 1 > [1.451531] Unable to handle kernel paging request at virtual address > ffec > [1.458734] pgd = c0004000 > [1.461430] [ffec] *pgd=2e7f5821, *pte=, *ppte= > [1.467698] Internal error: Oops: 17 [#2] PREEMPT SMP ARM > [1.473080] Modules linked in: > [1.476128] CPU: 0Tainted: G D (3.8.0-rc4-00154-g9fdb04c > #31) > [1.483163] PC is at kthread_data+0x4/0xc > [1.487161] LR is at wq_worker_sleeping+0xc/0xe8 > [1.491766] pc : []lr : []psr: 0193 > [1.491766] sp : ee061ba0 ip : fp : ee061c6c > [1.503217] r10: ee045350 r9 : ee0452d4 r8 : c06d9c40 > [1.508426] r7 : ee06 r6 : c0f82c40 r5 : r4 : > [1.514936] r3 : r2 :
Re: [PATCH] backlight: add an AS3711 PMIC backlight driver
On Wednesday, January 09, 2013 2:55 AM, Guennadi Liakhovetski wrote
>
> This is an initial commit of a backlight driver, using step-up DCDC power
> supplies on AS3711 PMIC. Only one mode has actually been tested, several
> further modes have been implemented "dry," but disabled to avoid accidental
> hardware damage. Anyone wishing to use any of those modes will have to
> modify the driver.
>
> Signed-off-by: Guennadi Liakhovetski
CC'ed Andrew Morton.
Hi Guennadi Liakhovetski,
I have reviewed this patch with AS3711 datasheet.
I cannot find any problems. It looks good.
However, some hardcoded numbers need to be changed
to the bit definitions.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> Tested on sh73a0-based kzm9g board. As the commit message says, only one
> mode has been tested and is enabled. That mode copies the sample code from
> the manufacturer. Deviations from that code proved to be fatal for the
> hardware...
>
> drivers/video/backlight/Kconfig |7 +
> drivers/video/backlight/Makefile|1 +
> drivers/video/backlight/as3711_bl.c | 379
> +++
> 3 files changed, 387 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/backlight/as3711_bl.c
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 765a945..6ef0ede 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -390,6 +390,13 @@ config BACKLIGHT_TPS65217
> If you have a Texas Instruments TPS65217 say Y to enable the
> backlight driver.
>
> +config BACKLIGHT_AS3711
> + tristate "AS3711 Backlight"
> + depends on BACKLIGHT_CLASS_DEVICE && MFD_AS3711
> + help
> + If you have an Austrian Microsystems AS3711 say Y to enable the
> + backlight driver.
> +
> endif # BACKLIGHT_CLASS_DEVICE
>
> endif # BACKLIGHT_LCD_SUPPORT
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index e7ce729..d3e188f 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_BACKLIGHT_PCF50633)+= pcf50633-backlight.o
> obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
> +obj-$(CONFIG_BACKLIGHT_AS3711) += as3711_bl.o
> diff --git a/drivers/video/backlight/as3711_bl.c
> b/drivers/video/backlight/as3711_bl.c
> new file mode 100644
> index 000..c6bc65d
> --- /dev/null
> +++ b/drivers/video/backlight/as3711_bl.c
> @@ -0,0 +1,379 @@
> +/*
> + * AS3711 PMIC backlight driver, using DCDC Step Up Converters
> + *
> + * Copyright (C) 2012 Renesas Electronics Corporation
> + * Author: Guennadi Liakhovetski,
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the version 2 of the GNU General Public License as
> + * published by the Free Software Foundation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum as3711_bl_type {
> + AS3711_BL_SU1,
> + AS3711_BL_SU2,
> +};
> +
> +struct as3711_bl_data {
> + bool powered;
> + const char *fb_name;
> + struct device *fb_dev;
> + enum as3711_bl_type type;
> + int brightness;
> + struct backlight_device *bl;
> +};
> +
> +struct as3711_bl_supply {
> + struct as3711_bl_data su1;
> + struct as3711_bl_data su2;
> + const struct as3711_bl_pdata *pdata;
> + struct as3711 *as3711;
> +};
> +
> +static struct as3711_bl_supply *to_supply(struct as3711_bl_data *su)
> +{
> + switch (su->type) {
> + case AS3711_BL_SU1:
> + return container_of(su, struct as3711_bl_supply, su1);
> + case AS3711_BL_SU2:
> + return container_of(su, struct as3711_bl_supply, su2);
> + }
> + return NULL;
> +}
> +
> +static int as3711_set_brightness_auto_i(struct as3711_bl_data *data,
> + unsigned int brightness)
> +{
> + struct as3711_bl_supply *supply = to_supply(data);
> + struct as3711 *as3711 = supply->as3711;
> + const struct as3711_bl_pdata *pdata = supply->pdata;
> + int ret = 0;
> +
> + /* Only all equal current values are supported */
> + if (pdata->su2_auto_curr1)
> + ret = regmap_write(as3711->regmap, AS3711_CURR1_VALUE,
> +brightness);
> + if (!ret && pdata->su2_auto_curr2)
> + ret = regmap_write(as3711->regmap, AS3711_CURR2_VALUE,
> +brightness);
> + if (!ret && pdata->su2_auto_curr3)
> + ret = regmap_write(as3711->regmap, AS3711_CURR3_VALUE,
> +brightness);
> +
> + return ret;
> +}
> +
> +static int as3711_set_brightness_v(struct as3711 *as3711,
> +unsigned int brightness,
> +
Re: [PATCH] vhost-net: fall back to vmalloc if high-order allocation fails
On Friday, January 25, 2013 03:03:13 AM Cong Wang wrote:
> ["Followup-To:" header set to gmane.linux.network.]
>
> On Wed, 23 Jan 2013 at 20:46 GMT, Romain Francoise
wrote:
> > Creating a vhost-net device allocates an object large enough (34320 bytes
> > on x86-64) to trigger an order-4 allocation, which may fail if memory if
> >
> > fragmented:
> > libvirtd: page allocation failure: order:4, mode:0x2000d0
> > ...
> > SLAB: Unable to allocate memory on node 0 (gfp=0xd0)
> >
> >cache: size-65536, object size: 65536, order: 4
> >node 0: slabs: 8/8, objs: 8/8, free: 0
> >
> > In that situation, rather than forcing the caller to use regular
> > virtio-net, try to allocate the descriptor with vmalloc().
>
> The real problem is vhost_net struct is really big, it
> should be reduced rather than workarounded like this.
>
Looks like iov in vhost_virtqueue is a little big:
struct iovec iov[UIO_MAXIOV];
Maybe we can use pointer and allocate it like indirect in
vhost_dev_alloc_iovecs().
> > +static void vhost_net_kvfree(void *addr)
> > +{
> > + if (is_vmalloc_addr(addr))
> > + vfree(addr);
> > + else
> > + kfree(addr);
> > +}
> > +
>
> This kind of stuff should really go to mm, not netdev.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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 V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 12:20 PM, Wanlong Gao wrote:
> On 01/25/2013 11:28 AM, Jason Wang wrote:
>> On 01/21/2013 07:25 PM, Wanlong Gao wrote:
>>> Split out the clean affinity function to virtnet_clean_affinity().
>>>
>>> Cc: Rusty Russell
>>> Cc: "Michael S. Tsirkin"
>>> Cc: Jason Wang
>>> Cc: Eric Dumazet
>>> Cc: virtualizat...@lists.linux-foundation.org
>>> Cc: net...@vger.kernel.org
>>> Signed-off-by: Wanlong Gao
>>> ---
>>> V5->V6: NEW
>>>
>>> drivers/net/virtio_net.c | 67
>>> +++-
>>> 1 file changed, 38 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 70cd957..1a35a8c 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
>>> net_device *dev, u16 vid)
>>> return 0;
>>> }
>>>
>>> -static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
>>> +static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
>>> {
>>> int i;
>>> int cpu;
>>>
>>> - /* In multiqueue mode, when the number of cpu is equal to the number of
>>> -* queue pairs, we let the queue pairs to be private to one cpu by
>>> -* setting the affinity hint to eliminate the contention.
>>> -*/
>>> - if ((vi->curr_queue_pairs == 1 ||
>>> -vi->max_queue_pairs != num_online_cpus()) && set) {
>>> - if (vi->affinity_hint_set)
>>> - set = false;
>>> - else
>>> - return;
>>> - }
>>> -
>>> - if (set) {
>>> - i = 0;
>>> - for_each_online_cpu(cpu) {
>>> - virtqueue_/set_affinity(vi->rq[i].vq, cpu);
>>> - virtqueue_set_affinity(vi->sq[i].vq, cpu);
>>> - *per_cpu_ptr(vi->vq_index, cpu) = i;
>>> - i++;
>>> - }
>>> -
>>> - vi->affinity_hint_set = true;
>>> - } else {
>>> - for(i = 0; i < vi->max_queue_pairs; i++) {
>>> + if (vi->affinity_hint_set) {
>>> + for (i = 0; i < vi->max_queue_pairs; i++) {
>>> virtqueue_set_affinity(vi->rq[i].vq, -1);
>>> virtqueue_set_affinity(vi->sq[i].vq, -1);
>>> }
>>>
>>> i = 0;
>>> - for_each_online_cpu(cpu)
>>> + for_each_online_cpu(cpu) {
>>> + if (cpu == hcpu)
>>> + continue;
>>> *per_cpu_ptr(vi->vq_index, cpu) =
>>> ++i % vi->curr_queue_pairs;
>>> + }
>>>
>> Some questions here:
>>
>> - Did we need reset the affinity of the queue here like the this?
>>
>> virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
>> virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
> I think no, we are going to unset the affinity of all the set queues,
> include hcpu.
>
>> - Looks like we need also reset the percpu index when
>> vi->affinity_hint_set is false.
> Yes, follow this and the comment on [1/3].
>
>> - Does this really need this reset? Consider we're going to reset the
>> percpu in CPU_DEAD?
> I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong queue
> on the dying CPU.
Didn't understand this. What does 'wrong queue' here mean? Looks like
you didn't change the preferable queue of the dying CPU and just change
all others.
>
> Thanks,
> Wanlong Gao
>
>> Thanks
>>> vi->affinity_hint_set = false;
>>> }
>>> }
>>>
>>> +static void virtnet_set_affinity(struct virtnet_info *vi)
>>> +{
>>> + int i;
>>> + int cpu;
>>> +
>>> + /* In multiqueue mode, when the number of cpu is equal to the number of
>>> +* queue pairs, we let the queue pairs to be private to one cpu by
>>> +* setting the affinity hint to eliminate the contention.
>>> +*/
>>> + if (vi->curr_queue_pairs == 1 ||
>>> + vi->max_queue_pairs != num_online_cpus()) {
>>> + if (vi->affinity_hint_set)
>>> + virtnet_clean_affinity(vi, -1);
>>> + else
>>> + return;
>>> + }
>>> +
>>> + i = 0;
>>> + for_each_online_cpu(cpu) {
>>> + virtqueue_set_affinity(vi->rq[i].vq, cpu);
>>> + virtqueue_set_affinity(vi->sq[i].vq, cpu);
>>> + *per_cpu_ptr(vi->vq_index, cpu) = i;
>>> + i++;
>>> + }
>>> +
>>> + vi->affinity_hint_set = true;
>>> +}
>>> +
>>> static void virtnet_get_ringparam(struct net_device *dev,
>>> struct ethtool_ringparam *ring)
>>> {
>>> @@ -1105,7 +1114,7 @@ static int virtnet_set_channels(struct net_device
>>> *dev,
>>> netif_set_real_num_rx_queues(dev, queue_pairs);
>>>
>>> get_online_cpus();
>>> - virtnet_set_affinity(vi, true);
>>> + virtnet_set_affinity(vi);
>>> put_online_cpus();
>>> }
>>>
>>> @@ -1274,7 +1283,7 @@ static void virtnet_del_vqs(struct
Re: [PATCH V6 2/3] virtio-net: split out clean affinity function
On 01/25/2013 11:28 AM, Jason Wang wrote:
> On 01/21/2013 07:25 PM, Wanlong Gao wrote:
>> Split out the clean affinity function to virtnet_clean_affinity().
>>
>> Cc: Rusty Russell
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc: Eric Dumazet
>> Cc: virtualizat...@lists.linux-foundation.org
>> Cc: net...@vger.kernel.org
>> Signed-off-by: Wanlong Gao
>> ---
>> V5->V6: NEW
>>
>> drivers/net/virtio_net.c | 67
>> +++-
>> 1 file changed, 38 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 70cd957..1a35a8c 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct
>> net_device *dev, u16 vid)
>> return 0;
>> }
>>
>> -static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
>> +static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
>> {
>> int i;
>> int cpu;
>>
>> -/* In multiqueue mode, when the number of cpu is equal to the number of
>> - * queue pairs, we let the queue pairs to be private to one cpu by
>> - * setting the affinity hint to eliminate the contention.
>> - */
>> -if ((vi->curr_queue_pairs == 1 ||
>> - vi->max_queue_pairs != num_online_cpus()) && set) {
>> -if (vi->affinity_hint_set)
>> -set = false;
>> -else
>> -return;
>> -}
>> -
>> -if (set) {
>> -i = 0;
>> -for_each_online_cpu(cpu) {
>> -virtqueue_/set_affinity(vi->rq[i].vq, cpu);
>> -virtqueue_set_affinity(vi->sq[i].vq, cpu);
>> -*per_cpu_ptr(vi->vq_index, cpu) = i;
>> -i++;
>> -}
>> -
>> -vi->affinity_hint_set = true;
>> -} else {
>> -for(i = 0; i < vi->max_queue_pairs; i++) {
>> +if (vi->affinity_hint_set) {
>> +for (i = 0; i < vi->max_queue_pairs; i++) {
>> virtqueue_set_affinity(vi->rq[i].vq, -1);
>> virtqueue_set_affinity(vi->sq[i].vq, -1);
>> }
>>
>> i = 0;
>> -for_each_online_cpu(cpu)
>> +for_each_online_cpu(cpu) {
>> +if (cpu == hcpu)
>> +continue;
>> *per_cpu_ptr(vi->vq_index, cpu) =
>> ++i % vi->curr_queue_pairs;
>> +}
>>
>
> Some questions here:
>
> - Did we need reset the affinity of the queue here like the this?
>
> virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
> virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
I think no, we are going to unset the affinity of all the set queues,
include hcpu.
>
> - Looks like we need also reset the percpu index when
> vi->affinity_hint_set is false.
Yes, follow this and the comment on [1/3].
> - Does this really need this reset? Consider we're going to reset the
> percpu in CPU_DEAD?
I think resetting when CPU_DOWN_PREPARE can avoid selecting the wrong queue
on the dying CPU.
Thanks,
Wanlong Gao
>
> Thanks
>> vi->affinity_hint_set = false;
>> }
>> }
>>
>> +static void virtnet_set_affinity(struct virtnet_info *vi)
>> +{
>> +int i;
>> +int cpu;
>> +
>> +/* In multiqueue mode, when the number of cpu is equal to the number of
>> + * queue pairs, we let the queue pairs to be private to one cpu by
>> + * setting the affinity hint to eliminate the contention.
>> + */
>> +if (vi->curr_queue_pairs == 1 ||
>> +vi->max_queue_pairs != num_online_cpus()) {
>> +if (vi->affinity_hint_set)
>> +virtnet_clean_affinity(vi, -1);
>> +else
>> +return;
>> +}
>> +
>> +i = 0;
>> +for_each_online_cpu(cpu) {
>> +virtqueue_set_affinity(vi->rq[i].vq, cpu);
>> +virtqueue_set_affinity(vi->sq[i].vq, cpu);
>> +*per_cpu_ptr(vi->vq_index, cpu) = i;
>> +i++;
>> +}
>> +
>> +vi->affinity_hint_set = true;
>> +}
>> +
>> static void virtnet_get_ringparam(struct net_device *dev,
>> struct ethtool_ringparam *ring)
>> {
>> @@ -1105,7 +1114,7 @@ static int virtnet_set_channels(struct net_device *dev,
>> netif_set_real_num_rx_queues(dev, queue_pairs);
>>
>> get_online_cpus();
>> -virtnet_set_affinity(vi, true);
>> +virtnet_set_affinity(vi);
>> put_online_cpus();
>> }
>>
>> @@ -1274,7 +1283,7 @@ static void virtnet_del_vqs(struct virtnet_info *vi)
>> {
>> struct virtio_device *vdev = vi->vdev;
>>
>> -virtnet_set_affinity(vi, false);
>> +virtnet_clean_affinity(vi, -1);
>>
>> vdev->config->del_vqs(vdev);
>>
>> @@ -1398,7 +1407,7 @@ static int init_vqs(struct virtnet_info
Re: [PATCH v2] PCI: Document PCIE BUS MPS parameters
[+cc Jon, can you make sure this documentation is accurate?] On Wed, Jan 23, 2013 at 7:58 PM, Yijing Wang wrote: > v0->v1: Update MPS parameters as non-arch and add MRRS > description into pcie_bus_perf parameter suggested > by Andrew Murray. > v1->v2: Update some semantic problems and add MPS and MRRS > explanation suggested by Joe Lawrence and Randy Dunlap. > > Document PCIE BUS MPS parameters pcie_bus_tune_off, pcie_bus_safe, > pcie_bus_peer2peer, pcie_bus_perf into Documentation/kernel-parameters.txt. > These parameters were introduced by Jon Mason at > commit 5f39e6705 and commit b03e7495a8. > > Signed-off-by: Yijing Wang > --- > Documentation/kernel-parameters.txt | 16 > 1 files changed, 16 insertions(+), 0 deletions(-) > > diff --git a/Documentation/kernel-parameters.txt > b/Documentation/kernel-parameters.txt > index 363e348..0bb279f 100644 > --- a/Documentation/kernel-parameters.txt > +++ b/Documentation/kernel-parameters.txt > @@ -2227,6 +2227,22 @@ bytes respectively. Such letter suffixes can also be > entirely omitted. > This sorting is done to get a device > order compatible with older (<= 2.4) kernels. > nobfsortDon't sort PCI devices into breadth-first > order. > + pcie_bus_tune_off Disable PCIe MPS (Max Payload Size) > + turning and using the BIOS-configured MPS > defaults. s/turning/tuning/ s/using/use/ > + pcie_bus_safe Use the smallest common denominator MPS > + of the entire tree below a root complex for > every > + device on that fabric. Can avoid inconsistent > MPS > + problem caused by hotplug. I'm not sure about this. "smallest common denominator" is colloquial and not exact. I think you probably mean "the smallest supported MPS of any device below a root complex." I'm also not sure how this will avoid MPS problems caused by hotplug. I think you have to assume that a hot-added device may support only a 128B MPS, which means the only way to guarantee that you can use that device is to set MPS=128 for any device that will send packets to the hot-added device. Or we could reconfigure things at the time of the hot-add, but I don't think we do that today (except for the hot-added device itself). > + pcie_bus_perf Configure pcie device MPS to the largest Capitalize "PCIe" consistently. Better yet, drop it completely since it's obvious that we're only talking about PCIe here. > + allowable MPS based on its parent bus. Also > set > + MRRS (Max Read Request Size) to the largest > supported > + value (no larger than the MPS that the device > or bus > + can support) for Max performance. s/Max/best/ > + pcie_bus_peer2peer Make the system-wide MPS the smallest > + possible value (128B). This configuration > could prevent > + peer to peer DMA transmission from working by > having > + the MPS on one root port different than the > MPS on > + another. I think the idea is that pcie_bus_peer2peer would *allow* peer-to-peer DMA to work, which is the opposite of what you wrote. Maybe something like this would be better: Set every device's MPS to 128B, which every device is guaranteed to support. This configuration allows peer-to-peer DMA between any pair of devices, possibly at the cost of reduced performance. > cbiosize=nn[KMG]The fixed amount of bus space which is > reserved for the CardBus bridge's IO window. > The default value is 256 bytes. > -- > 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/
Re: [PATCH 1/3] regulator: max8907: Fix using wrong dev argument for calling of_regulator_match
On 01/24/2013 06:20 PM, Axel Lin wrote: > The dev parameter is the device requesting the data. > In this case it should be >dev rather than pdev->dev.parent. > > The dev parameter is used to call devm_kzalloc in > of_get_regulator_init_data(), > which means this fixes a memory leak because the memory is allocated every > time > probe() is called, thus it should be freed when this driver is unloaded. Reviewed-by: Stephen Warren -- 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] x86, reboot: skip reboot_fixups in early boot phase
On Thu, Jan 24, 2013 at 09:21:52PM -0700, Bjorn Helgaas wrote:
> On Thu, Jan 24, 2013 at 9:14 PM, Greg Kroah-Hartman
> wrote:
> > On Thu, Jan 24, 2013 at 07:59:01PM -0700, Bjorn Helgaas wrote:
> >> [+cc Greg for driver core]
> >>
> >> On Fri, Jan 25, 2013 at 10:13:03AM +0900, Joonsoo Kim wrote:
> >> > Hello, Bjorn.
> >> >
> >> > On Thu, Jan 24, 2013 at 10:45:13AM -0700, Bjorn Helgaas wrote:
> >> > > On Fri, Dec 28, 2012 at 6:50 AM, Joonsoo Kim wrote:
> >> > > > During early boot phase, PCI bus subsystem is not yet initialized.
> >> > > > If panic is occured in early boot phase and panic_timeout is set,
> >> > > > code flow go into emergency_restart() and hit mach_reboot_fixups(),
> >> > > > then
> >> > > > encounter another panic. When second panic, we can't hold a
> >> > > > panic_lock, so
> >> > > > code flow go into panic_smp_self_stop() which prevent system to
> >> > > > restart.
> >> > > >
> >> > > > For avoid second panic, skip reboot_fixups in early boot phase.
> >> > > > It makes panic_timeout works in early boot phase.
> >> > > >
> >> > > > Cc: Thomas Gleixner
> >> > > > Cc: Ingo Molnar
> >> > > > Cc: "H. Peter Anvin"
> >> > > > Signed-off-by: Joonsoo Kim
> >> > > >
> >> > > > diff --git a/arch/x86/kernel/reboot_fixups_32.c
> >> > > > b/arch/x86/kernel/reboot_fixups_32.c
> >> > > > index c8e41e9..b9b8ec9 100644
> >> > > > --- a/arch/x86/kernel/reboot_fixups_32.c
> >> > > > +++ b/arch/x86/kernel/reboot_fixups_32.c
> >> > > > @@ -89,6 +89,10 @@ void mach_reboot_fixups(void)
> >> > > > if (in_interrupt())
> >> > > > return;
> >> > > >
> >> > > > + /* During early boot phase, PCI is not yet initialized */
> >> > > > + if (system_state == SYSTEM_BOOTING)
> >> > > > + return;
> >> > > > +
> >> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
> >> > > > cur = &(fixups_table[i]);
> >> > > > dev = pci_get_device(cur->vendor, cur->device, NULL);
> >> > >
> >> > > I guess you're saying that if we call pci_get_device() too early, it
> >> > > panics? Did you figure out why that happens?
> >> > >
> >> > > If we call pci_get_device() before PCI has been initialized, it would
> >> > > be good if it just returned NULL, indicating that we didn't find any
> >> > > matching device. I looked briefly, and I thought that's what would
> >> > > happen, but apparently I'm missing something.
> >> >
> >> > In bus_find_device(), klist_iter_init_node() is called with
> >> > @bus->p->klist_device. Before initialization, bus->p is NULL,
> >> > so panic is occured.
> >>
> >> I see. pci_bus_type.p is initialized by __bus_register() in this path:
> >>
> >> pci_driver_init# postcore_initcall
> >> bus_register(_bus_type)
> >> __bus_register
> >> priv = kzalloc(sizeof(struct subsys_private))
> >> bus->p = priv
> >> klist_init(>klist_devices, klist_devices_get,
> >> klist_devices_put)
> >>
> >> I was hoping we could statically initialize the klist, but that doesn't
> >> seem likely.
> >>
> >> But I wonder if we could do something like the following. If we could,
> >> then callers wouldn't have to worry about whether or not the bus has been
> >> initialized.
> >
> >
> >
> > I have no objection to that patch, but really, someone wants to call
> > pci_find_device() before PCI is initialized? Can't that be fixed
> > instead, as that is the root problem, not the driver core.
> >
> > But, to paper over your subsystem's bugs, I guess I can take it :)
>
> The caller is in the native_machine_emergency_restart() path.
> Joonsoo's original patch does what I think you're suggesting:
>
> >> > > > + /* During early boot phase, PCI is not yet initialized */
> >> > > > + if (system_state == SYSTEM_BOOTING)
> >> > > > + return;
> >> > > > +
> >> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
> >> > > > cur = &(fixups_table[i]);
> >> > > > dev = pci_get_device(cur->vendor, cur->device, NULL);
>
> I think it's sort of ugly to check system_state before using
> pci_get_device(), and there's not really an obvious connection between
> system_state and PCI initialization.
>
> But if you prefer that, Joonsoo's original patch is fine with me.
Both probably would be best, as there are probably other things that you
don't want to touch when you are still booting and trying to restart the
machine at the same time.
thanks,
greg k-h
--
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/7] clk: tegra: Use common of_clk_init() function
On 01/24/2013 04:57 PM, Mike Turquette wrote: > Quoting Stephen Warren (2013-01-24 11:32:37) >> On 01/24/2013 11:20 AM, Mike Turquette wrote: >>> Quoting Prashant Gaikwad (2013-01-04 18:44:48) On Friday 04 January 2013 10:00 PM, Stephen Warren wrote: > On 01/04/2013 12:00 AM, Prashant Gaikwad wrote: >> Use common of_clk_init() function for clocks initialization. >> drivers/clk/tegra/clk-tegra20.c |3 ++- >> drivers/clk/tegra/clk-tegra30.c |3 ++- > Oh, so this series is written assuming that the Tegra CCF rework is > already applied then? That makes the dependencies quite painful, since I > think we'll end up with the following order being needed: > > 1) clk: Add composite clock type > -> This would usually go through the clk tree. > 2) The Tegra CCF rework series > -> This must go through the Tegra tree due to lots of dependencies > and merge conflicts with other Tegra patches. > 3) This series > -> This would usually go through the clk tree. > > Is it possible to re-order the dependencies as (1) (3) (2), so that Mike > can apply (1) and (3) to the clock tree, then I can use the clk tree as > the basis for a branch in the Tegra tree to apply (2) and all the other > Tegra patches that will conflict with (2)? If Mike approves the concept and implementation in (1) and (3) then I will repost (2) and (3) with dependencies re-ordered. >>> >>> Patch (1) still has some unaddressed comments, and is not a real >>> dependency for this series. >> >> I assume "Patch (1)" refers to the list of series a couple emails above, >> not the first patch in the series you're replying to; that threw me for >> a moment. >> >>> Since all of the patches have received their >>> Tested-by's then I propose to merge all patches from this series into >>> clk-next, which exception of patch 2/7 (the Tegra patch). >>> >>> This reduces your Tegra CCF conversion dependencies and you can role the >>> necessary of_clk_init change into your Tegra CCF conversion branch (it >>> has my implicit Ack and can be taken through your tree). >>> >>> Let me know if this is OK for you. >> >> OK, I'm happy to merge your clock tree into the Tegra tree and then >> apply 2/7 on top of the Tegra CCF work. > > Hmm, maybe the clk tree needs to be a dependency branch of arm-soc > again, as it has in the past. Would that help with any Tegra merge > pain? Yes, I think that's what would end up happening if I merge the clk tree into the Tegra tree anyway. -- 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/2] kvm: IOMMU read-only mapping support
On Fri, 25 Jan 2013 12:59:12 +0900 Takuya Yoshikawa wrote: > > The commit c972f3b1 changed the write-protect behaviour - it does > > wirte-protection only when dirty flag is set. > > [ I did not see this commit when we discussed the problem before. ] > > I'll look at the commit later, after the lunch break. I've done! So we need to do: if (npages && (GET_DIRTY || RDONLY)) write protect About sync_page, I'm not sure what is the best fix. Takuya > > > Further more, i notice that write-protect is not enough, when do sync > > shadow page: > > > > FNAME(sync_page): > > > > host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE; > > > > set_spte(vcpu, >spt[i], pte_access, > > PT_PAGE_TABLE_LEVEL, gfn, > > spte_to_pfn(sp->spt[i]), true, false, > > host_writable); > > > > It sets spte based on the old value that means the readonly flag check > > is missed. We need to call kvm_arch_flush_shadow_all under this case. > > So the change needed will be in arch/x86. > in arch_commit_* one. > > Right? > > Note: I'm not touching arch_* memory slot APIs now because ARM KVM > is coming now. So no problem, the flags will be passed as before. > > Takuya -- Takuya Yoshikawa -- 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: boot warnings due to swap: make each swap partition have one address_space
On Thu, Jan 24, 2013 at 10:45:57PM -0500, Sasha Levin wrote:
> Hi folks,
>
> Commit "swap: make each swap partition have one address_space" is triggering
> a series of warnings on boot:
>
> [3.446071] [ cut here ]
> [3.446664] WARNING: at lib/debugobjects.c:261
> debug_print_object+0x8e/0xb0()
> [3.447715] ODEBUG: init active (active state 0) object type:
> percpu_counter hint: (null)
> [3.450360] Modules linked in:
> [3.451593] Pid: 1, comm: swapper/0 Tainted: GW
> 3.8.0-rc4-next-20130124-sasha-4-g838a1b4 #266
> [3.454508] Call Trace:
> [3.455248] [] warn_slowpath_common+0x8c/0xc0
> [3.455248] [] warn_slowpath_fmt+0x41/0x50
> [3.455248] [] debug_print_object+0x8e/0xb0
> [3.455248] [] __debug_object_init+0x20b/0x290
> [3.455248] [] debug_object_init+0x15/0x20
> [3.455248] [] __percpu_counter_init+0x6d/0xe0
> [3.455248] [] bdi_init+0x1ac/0x270
> [3.455248] [] swap_setup+0x3b/0x87
> [3.455248] [] ? swap_setup+0x87/0x87
> [3.455248] [] kswapd_init+0x11/0x7c
> [3.455248] [] do_one_initcall+0x8a/0x180
> [3.455248] [] do_basic_setup+0x96/0xb4
> [3.455248] [] ? loglevel+0x31/0x31
> [3.455248] [] ? sched_init_smp+0x150/0x157
> [3.455248] [] kernel_init_freeable+0xd2/0x14c
> [3.455248] [] ? rest_init+0x140/0x140
> [3.455248] [] kernel_init+0x9/0xf0
> [3.455248] [] ret_from_fork+0x7c/0xb0
> [3.455248] [] ? rest_init+0x140/0x140
> [3.455248] ---[ end trace 0b176d5c0f21bffb ]---
>
> I haven't looked deeper into it yet, and will do so tomorrow, unless this
> spew is obvious to anyone.
Does this one help?
Subject: give-each-swapper-space-separate-backing_dev_info
The backing_dev_info can't be shared by all swapper address space.
Reported-by: Sasha Levin
Signed-off-by: Shaohua Li
---
mm/swap.c |1 +
mm/swap_state.c | 11 +++
2 files changed, 8 insertions(+), 4 deletions(-)
Index: linux/mm/swap.c
===
--- linux.orig/mm/swap.c2013-01-22 10:11:58.310933234 +0800
+++ linux/mm/swap.c 2013-01-25 12:14:49.524863610 +0800
@@ -859,6 +859,7 @@ void __init swap_setup(void)
int i;
for (i = 0; i < MAX_SWAPFILES; i++) {
+ swapper_spaces[i].backing_dev_info += i;
bdi_init(swapper_spaces[i].backing_dev_info);
spin_lock_init(_spaces[i].tree_lock);
INIT_LIST_HEAD(_spaces[i].i_mmap_nonlinear);
Index: linux/mm/swap_state.c
===
--- linux.orig/mm/swap_state.c 2013-01-24 18:08:05.149390977 +0800
+++ linux/mm/swap_state.c 2013-01-25 12:14:12.849323671 +0800
@@ -31,16 +31,19 @@ static const struct address_space_operat
.migratepage= migrate_page,
};
-static struct backing_dev_info swap_backing_dev_info = {
- .name = "swap",
- .capabilities = BDI_CAP_NO_ACCT_AND_WRITEBACK | BDI_CAP_SWAP_BACKED,
+static struct backing_dev_info swap_backing_dev_info[MAX_SWAPFILES] = {
+ [0 ... MAX_SWAPFILES - 1] = {
+ .name = "swap",
+ .capabilities = BDI_CAP_NO_ACCT_AND_WRITEBACK |
+ BDI_CAP_SWAP_BACKED,
+ }
};
struct address_space swapper_spaces[MAX_SWAPFILES] = {
[0 ... MAX_SWAPFILES - 1] = {
.page_tree = RADIX_TREE_INIT(GFP_ATOMIC|__GFP_NOWARN),
.a_ops = _aops,
- .backing_dev_info = _backing_dev_info,
+ .backing_dev_info = _backing_dev_info[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] pci: remove redundant function calls in pci_reassigndev_resource_alignment()
On Fri, Dec 28, 2012 at 1:55 AM, Lin Feng wrote:
>
>
> On 12/28/2012 03:45 PM, Yinghai Lu wrote:
>> On Thu, Dec 27, 2012 at 11:31 PM, Lin Feng wrote:
>>> pci_reassigndev_resource_alignment() potentially calls
>>> pci_specified_resource_alignment() twice, which is redundant.
>>>
>>> pci_is_reassigndev() is only called in pci_reassigndev_resource_alignment(),
>>> and from sematic/functionality aspects pci_specified_resource_alignment() is
>>> sufficient to substitute, so also make some cleanup.
>>>
>>> Signed-off-by: Lin Feng
>>> Cc: Yinghai Lu
>>> ---
>>> drivers/pci/pci.c | 16 ++--
>>> 1 files changed, 2 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 5cb5820..789f401 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3766,18 +3766,6 @@ resource_size_t
>>> pci_specified_resource_alignment(struct pci_dev *dev)
>>> return align;
>>> }
>>>
>>> -/**
>>> - * pci_is_reassigndev - check if specified PCI is target device to reassign
>>> - * @dev: the PCI device to check
>>> - *
>>> - * RETURNS: non-zero for PCI device is a target device to reassign,
>>> - * or zero is not.
>>> - */
>>> -int pci_is_reassigndev(struct pci_dev *dev)
>>> -{
>>> - return (pci_specified_resource_alignment(dev) != 0);
>>> -}
>>> -
>>> /*
>>> * This function disables memory decoding and releases memory resources
>>> * of the device specified by kernel's boot parameter
>>> 'pci=resource_alignment='.
>>> @@ -3792,7 +3780,8 @@ void pci_reassigndev_resource_alignment(struct
>>> pci_dev *dev)
>>> resource_size_t align, size;
>>> u16 command;
>>>
>>> - if (!pci_is_reassigndev(dev))
>>> + align = pci_specified_resource_alignment(dev);
>>> + if (!align)
>>> return;
>>>
>>> if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
>>> @@ -3808,7 +3797,6 @@ void pci_reassigndev_resource_alignment(struct
>>> pci_dev *dev)
>>> command &= ~PCI_COMMAND_MEMORY;
>>> pci_write_config_word(dev, PCI_COMMAND, command);
>>>
>>> - align = pci_specified_resource_alignment(dev);
>>> for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
>>> r = >resource[i];
>>> if (!(r->flags & IORESOURCE_MEM))
>>> --
>>> 1.7.1
>>>
>>
>> looks the same as the one that i posted 6 months ago.
>>
>> http://copilotco.com/mail-archives/linux-kernel.2012/msg18498.html
> Sorry, I didn't notice your patchset before :)
> Yes, they are the same. But why does nobody care this?
I applied Yinghai's patch to my pci/misc branch, headed for v3.9.
Bjorn
--
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] x86, reboot: skip reboot_fixups in early boot phase
On Thu, Jan 24, 2013 at 9:14 PM, Greg Kroah-Hartman
wrote:
> On Thu, Jan 24, 2013 at 07:59:01PM -0700, Bjorn Helgaas wrote:
>> [+cc Greg for driver core]
>>
>> On Fri, Jan 25, 2013 at 10:13:03AM +0900, Joonsoo Kim wrote:
>> > Hello, Bjorn.
>> >
>> > On Thu, Jan 24, 2013 at 10:45:13AM -0700, Bjorn Helgaas wrote:
>> > > On Fri, Dec 28, 2012 at 6:50 AM, Joonsoo Kim wrote:
>> > > > During early boot phase, PCI bus subsystem is not yet initialized.
>> > > > If panic is occured in early boot phase and panic_timeout is set,
>> > > > code flow go into emergency_restart() and hit mach_reboot_fixups(),
>> > > > then
>> > > > encounter another panic. When second panic, we can't hold a
>> > > > panic_lock, so
>> > > > code flow go into panic_smp_self_stop() which prevent system to
>> > > > restart.
>> > > >
>> > > > For avoid second panic, skip reboot_fixups in early boot phase.
>> > > > It makes panic_timeout works in early boot phase.
>> > > >
>> > > > Cc: Thomas Gleixner
>> > > > Cc: Ingo Molnar
>> > > > Cc: "H. Peter Anvin"
>> > > > Signed-off-by: Joonsoo Kim
>> > > >
>> > > > diff --git a/arch/x86/kernel/reboot_fixups_32.c
>> > > > b/arch/x86/kernel/reboot_fixups_32.c
>> > > > index c8e41e9..b9b8ec9 100644
>> > > > --- a/arch/x86/kernel/reboot_fixups_32.c
>> > > > +++ b/arch/x86/kernel/reboot_fixups_32.c
>> > > > @@ -89,6 +89,10 @@ void mach_reboot_fixups(void)
>> > > > if (in_interrupt())
>> > > > return;
>> > > >
>> > > > + /* During early boot phase, PCI is not yet initialized */
>> > > > + if (system_state == SYSTEM_BOOTING)
>> > > > + return;
>> > > > +
>> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
>> > > > cur = &(fixups_table[i]);
>> > > > dev = pci_get_device(cur->vendor, cur->device, NULL);
>> > >
>> > > I guess you're saying that if we call pci_get_device() too early, it
>> > > panics? Did you figure out why that happens?
>> > >
>> > > If we call pci_get_device() before PCI has been initialized, it would
>> > > be good if it just returned NULL, indicating that we didn't find any
>> > > matching device. I looked briefly, and I thought that's what would
>> > > happen, but apparently I'm missing something.
>> >
>> > In bus_find_device(), klist_iter_init_node() is called with
>> > @bus->p->klist_device. Before initialization, bus->p is NULL,
>> > so panic is occured.
>>
>> I see. pci_bus_type.p is initialized by __bus_register() in this path:
>>
>> pci_driver_init# postcore_initcall
>> bus_register(_bus_type)
>> __bus_register
>> priv = kzalloc(sizeof(struct subsys_private))
>> bus->p = priv
>> klist_init(>klist_devices, klist_devices_get, klist_devices_put)
>>
>> I was hoping we could statically initialize the klist, but that doesn't
>> seem likely.
>>
>> But I wonder if we could do something like the following. If we could,
>> then callers wouldn't have to worry about whether or not the bus has been
>> initialized.
>
>
>
> I have no objection to that patch, but really, someone wants to call
> pci_find_device() before PCI is initialized? Can't that be fixed
> instead, as that is the root problem, not the driver core.
>
> But, to paper over your subsystem's bugs, I guess I can take it :)
The caller is in the native_machine_emergency_restart() path.
Joonsoo's original patch does what I think you're suggesting:
>> > > > + /* During early boot phase, PCI is not yet initialized */
>> > > > + if (system_state == SYSTEM_BOOTING)
>> > > > + return;
>> > > > +
>> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
>> > > > cur = &(fixups_table[i]);
>> > > > dev = pci_get_device(cur->vendor, cur->device, NULL);
I think it's sort of ugly to check system_state before using
pci_get_device(), and there's not really an obvious connection between
system_state and PCI initialization.
But if you prefer that, Joonsoo's original patch is fine with me.
--
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/5] jump label: constify lookup functions
On 01/18/2013 04:25 PM, Steven Rostedt wrote:
> On Wed, 2013-01-09 at 18:09 -0500, Sasha Levin wrote:
>> Modify the parameters of all the lookup and the bookkeeping functions which
>> should be const to const.
>>
>> For example, jump_label_text_reserved() doesn't modify the memory it works
>> on,
>> it just checks whether there are any jump labels there.
>
> This is dependent on the module patch, which Rusty is taking. I need to
> see that he has it before this can go in. At least see it in linux-next.
>
> Also, you should have Cc'd the linux-arch mailing list. I'll send it
> there.
>
>>
>> Note I couldn't test the non-x86 architectures, but the changes are rather
>> trivial.
>
> I ran it on 25 archs, and s390 hit:
>
> /work/autotest/nobackup/cross-linux.git/arch/s390/kernel/jump_label.c: In
> function 'arch_jump_label_transform':
> /work/autotest/nobackup/cross-linux.git/arch/s390/kernel/jump_label.c:58:13:
> warning: assignment discards 'const' qualifier from pointer target type
> [enabled by default]
>
> -- Steve
>
> Here's the patch:
>
> Signed-off-by: Steven Rostedt
>
> diff --git a/arch/s390/kernel/jump_label.c
> b/arch/s390/kernel/jump_label.c
> index 85fa643..ef047ef 100644
> --- a/arch/s390/kernel/jump_label.c
> +++ b/arch/s390/kernel/jump_label.c
> @@ -18,7 +18,7 @@ struct insn {
> } __packed;
>
> struct insn_args {
> - struct jump_entry *entry;
> + const struct jump_entry *entry;
> enum jump_label_type type;
> };
>
Sorry about this. I didn't have the ability to build all arches over here :(
Would you like me to resend this patch with your fix?
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3.5] dw_dmac: return proper residue value
On Thu, Jan 24, 2013 at 6:37 PM, Andy Shevchenko
wrote:
> Currently the driver returns full length of the active descriptor which is
> wrong. We have to go throught the active descriptor and substract the length
> of
> each sent children in the chain from the total length along with the actual
> data in the DMA channel registers.
>
> The cyclic case is not handled by this patch due to len field in the
> descriptor
> structure is left untouched by the original code.
>
> Signed-off-by: Andy Shevchenko
Firstly the issue i raised earlier about not updating residue from
tasklet or interrupt
handler was wrong. As i had an older version of code in my mind. This got solved
with following patch:
commit 77bcc497c60ec62dbb84abc809a6e218d53409e9
Author: Andy Shevchenko
Date: Fri Jan 18 14:14:15 2013 +0200
dw_dmac: move soft LLP code from tasklet to dwc_scan_descriptors
> ---
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> +static inline u32 dwc_get_residue(struct dw_dma_chan *dwc)
> +{
> + unsigned long flags;
> + u32 residue;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + residue = dwc->residue;
you need to release the lock just here.
> + if (test_bit(DW_DMA_IS_SOFT_LLP, >flags) && residue)
> + residue -= dwc_get_sent(dwc);
why do you need lock while reading the control registers? It looks you didn't
get what i wanted to say earlier. We are using locks to protect some part for
shared data or critical sections. these are playing with dwc transfer
lists, etc..
Probably we don't need a lock to read the control register as nobody can
guarantee that another access is not happening currently. As hardware is
changing this register continuously for the transfer.
Let me know if i am missing something.
> + spin_unlock_irqrestore(>lock, flags);
> + return residue;
> +}
--
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] x86, reboot: skip reboot_fixups in early boot phase
On Thu, Jan 24, 2013 at 07:59:01PM -0700, Bjorn Helgaas wrote:
> [+cc Greg for driver core]
>
> On Fri, Jan 25, 2013 at 10:13:03AM +0900, Joonsoo Kim wrote:
> > Hello, Bjorn.
> >
> > On Thu, Jan 24, 2013 at 10:45:13AM -0700, Bjorn Helgaas wrote:
> > > On Fri, Dec 28, 2012 at 6:50 AM, Joonsoo Kim wrote:
> > > > During early boot phase, PCI bus subsystem is not yet initialized.
> > > > If panic is occured in early boot phase and panic_timeout is set,
> > > > code flow go into emergency_restart() and hit mach_reboot_fixups(), then
> > > > encounter another panic. When second panic, we can't hold a panic_lock,
> > > > so
> > > > code flow go into panic_smp_self_stop() which prevent system to restart.
> > > >
> > > > For avoid second panic, skip reboot_fixups in early boot phase.
> > > > It makes panic_timeout works in early boot phase.
> > > >
> > > > Cc: Thomas Gleixner
> > > > Cc: Ingo Molnar
> > > > Cc: "H. Peter Anvin"
> > > > Signed-off-by: Joonsoo Kim
> > > >
> > > > diff --git a/arch/x86/kernel/reboot_fixups_32.c
> > > > b/arch/x86/kernel/reboot_fixups_32.c
> > > > index c8e41e9..b9b8ec9 100644
> > > > --- a/arch/x86/kernel/reboot_fixups_32.c
> > > > +++ b/arch/x86/kernel/reboot_fixups_32.c
> > > > @@ -89,6 +89,10 @@ void mach_reboot_fixups(void)
> > > > if (in_interrupt())
> > > > return;
> > > >
> > > > + /* During early boot phase, PCI is not yet initialized */
> > > > + if (system_state == SYSTEM_BOOTING)
> > > > + return;
> > > > +
> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
> > > > cur = &(fixups_table[i]);
> > > > dev = pci_get_device(cur->vendor, cur->device, NULL);
> > >
> > > I guess you're saying that if we call pci_get_device() too early, it
> > > panics? Did you figure out why that happens?
> > >
> > > If we call pci_get_device() before PCI has been initialized, it would
> > > be good if it just returned NULL, indicating that we didn't find any
> > > matching device. I looked briefly, and I thought that's what would
> > > happen, but apparently I'm missing something.
> >
> > In bus_find_device(), klist_iter_init_node() is called with
> > @bus->p->klist_device. Before initialization, bus->p is NULL,
> > so panic is occured.
>
> I see. pci_bus_type.p is initialized by __bus_register() in this path:
>
> pci_driver_init# postcore_initcall
> bus_register(_bus_type)
> __bus_register
> priv = kzalloc(sizeof(struct subsys_private))
> bus->p = priv
> klist_init(>klist_devices, klist_devices_get, klist_devices_put)
>
> I was hoping we could statically initialize the klist, but that doesn't
> seem likely.
>
> But I wonder if we could do something like the following. If we could,
> then callers wouldn't have to worry about whether or not the bus has been
> initialized.
I have no objection to that patch, but really, someone wants to call
pci_find_device() before PCI is initialized? Can't that be fixed
instead, as that is the root problem, not the driver core.
But, to paper over your subsystem's bugs, I guess I can take it :)
Care to resend it in a format that I can apply it in?
thanks,
greg k-h
--
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/5] kprobes: constify check_kprobe_address_safe and friends
Hello Masami,
Thank you for your review!
My comments are below.
On 01/21/2013 06:49 AM, Masami Hiramatsu wrote:
> (2013/01/10 8:09), Sasha Levin wrote:
>> @@ -278,7 +278,7 @@ static int __kprobes can_optimize(unsigned long paddr)
>> }
>>
>> /* Check optimized_kprobe can actually be optimized. */
>> -int __kprobes arch_check_optimized_kprobe(struct optimized_kprobe *op)
>> +int __kprobes arch_check_optimized_kprobe(const struct optimized_kprobe *op)
>> {
>> int i;
>> struct kprobe *p;
>
> This can be change optimized_kprobe inside, e.g. change flags.
> IMHO, I don't like to change this interface.
[snip]
>> -static __kprobes int check_kprobe_address_safe(struct kprobe *p,
>> +static __kprobes int check_kprobe_address_safe(const struct kprobe *p,
>> struct module **probed_mod)
>> {
>> int ret = 0;
>>
>
> No, p is NOT constant in this function. This changes p->flags.
>
> ---
> #ifdef KPROBES_CAN_USE_FTRACE
> /* Given address is not on the instruction boundary */
> if ((unsigned long)p->addr != ftrace_addr)
> return -EILSEQ;
> p->flags |= KPROBE_FLAG_FTRACE;
> #else /* !KPROBES_CAN_USE_FTRACE */
As to arch_check_optimized_kprobe() and check_kprobe_address_safe(), this
is simply way too confusing. It doesn't make sense that a function named
check_[...]() would modify any of it's parameters.
For example, that entire block within KPROBES_CAN_USE_FTRACE should be split
out and go into update_kprobe_for_ftrace() or something similar.
If that makes sense, I can send a patch to split out all the parts that
modify anything in those two functions out of them.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] clk: vt8500: Use common of_clk_init() function
On Thu, 2013-01-24 at 11:15 -0800, Mike Turquette wrote:
> Quoting Tony Prisk (2013-01-18 13:08:00)
> > On Fri, 2013-01-18 at 09:56 -0800, Mike Turquette wrote:
> > > Quoting Prashant Gaikwad (2013-01-03 23:00:56)
> > > > Use common of_clk_init() function for clock initialization.
> > > >
> > > > Signed-off-by: Prashant Gaikwad
> > >
> > > Tony,
> > >
> > > Can I get a Tested-by from you before I take this in?
> > >
> > Tested-by: Tony Prisk
> >
> > FYI: This will need another patch to complete as we added another set of
> > clocks to this clk-vt8500.c for 3.9.
> >
>
> Tony, is the following patch correct?
>
>
> From 5b6e0adb69674c684c33503f50010644b049029c Mon Sep 17 00:00:00 2001
> From: Prashant Gaikwad
> Date: Fri, 4 Jan 2013 12:30:56 +0530
> Subject: [PATCH] clk: vt8500: Use common of_clk_init() function
>
> Use common of_clk_init() function for clock initialization.
>
> Signed-off-by: Prashant Gaikwad
> Tested-by: Tony Prisk
> Signed-off-by: Mike Turquette
> [mturque...@linaro.org: added entry for wm8750-pll-clock]
>
> Signed-off-by: Mike Turquette
> ---
> drivers/clk/clk-vt8500.c | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
> index 2515d4f..b5538bb 100644
> --- a/drivers/clk/clk-vt8500.c
> +++ b/drivers/clk/clk-vt8500.c
> @@ -291,7 +291,7 @@ static __init void vtwm_device_clk_init(struct
> device_node *node)
> rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
> clk_register_clkdev(clk, clk_name, NULL);
> }
> -
> +CLK_OF_DECLARE(vt8500_device, "via,vt8500-device-clock",
> vtwm_device_clk_init);
>
> /* PLL clock related functions */
>
> @@ -612,26 +612,19 @@ static void __init vt8500_pll_init(struct device_node
> *node)
> {
> vtwm_pll_clk_init(node, PLL_TYPE_VT8500);
> }
> +CLK_OF_DECLARE(vt8500_pll, "via,vt8500-pll-clock", vt8500_pll_init);
>
> static void __init wm8650_pll_init(struct device_node *node)
> {
> vtwm_pll_clk_init(node, PLL_TYPE_WM8650);
> }
> +CLK_OF_DECLARE(wm8650_pll, "wm,wm8650-pll-clock", wm8650_pll_init);
>
> static void __init wm8750_pll_init(struct device_node *node)
> {
> vtwm_pll_clk_init(node, PLL_TYPE_WM8750);
> }
> -
> -static const __initconst struct of_device_id clk_match[] = {
> - { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> - { .compatible = "via,vt8500-pll-clock", .data = vt8500_pll_init, },
> - { .compatible = "wm,wm8650-pll-clock", .data = wm8650_pll_init, },
> - { .compatible = "wm,wm8750-pll-clock", .data = wm8750_pll_init, },
> - { .compatible = "via,vt8500-device-clock",
> - .data = vtwm_device_clk_init, },
> - { /* sentinel */ }
> -};
> +CLK_OF_DECLARE(wm8750_pll, "wm,wm8750-pll-clock", wm8750_pll_init);
>
> void __init vtwm_clk_init(void __iomem *base)
> {
> @@ -640,5 +633,5 @@ void __init vtwm_clk_init(void __iomem *base)
>
> pmc_base = base;
>
> - of_clk_init(clk_match);
> + of_clk_init(NULL);
> }
Yeap - this patch is fine.
Tested-by: Tony Prisk
Acked-by: Tony Prisk
Take your pick which signoff you want :)
Regards
Tony P
--
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/2] kvm: IOMMU read-only mapping support
On Fri, 25 Jan 2013 11:28:40 +0800 Xiao Guangrong wrote: > > I think I can naturally update my patch after this gets merged. > > > > Please wait. The patch I mentioned above won't change anything. Just cleans up set_memory_region(). The only possible change which we discussed before was whether we call iommu_map() on a flags change. > The commit c972f3b1 changed the write-protect behaviour - it does > wirte-protection only when dirty flag is set. > [ I did not see this commit when we discussed the problem before. ] I'll look at the commit later, after the lunch break. > Further more, i notice that write-protect is not enough, when do sync > shadow page: > > FNAME(sync_page): > > host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE; > > set_spte(vcpu, >spt[i], pte_access, >PT_PAGE_TABLE_LEVEL, gfn, >spte_to_pfn(sp->spt[i]), true, false, >host_writable); > > It sets spte based on the old value that means the readonly flag check > is missed. We need to call kvm_arch_flush_shadow_all under this case. So the change needed will be in arch/x86. in arch_commit_* one. Right? Note: I'm not touching arch_* memory slot APIs now because ARM KVM is coming now. So no problem, the flags will be passed as before. Takuya -- 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/8] mm: use vm_unmapped_area() on alpha architecture
On 9/01/2013, at 2:28 PM, Michel Lespinasse wrote: Update the alpha arch_get_unmapped_area function to make use of vm_unmapped_area() instead of implementing a brute force search. Signed-off-by: Michel Lespinasse 'Tis running fine on my alpha. Tested-by: Michael Cree Cheers Michael. -- 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] efivars write(2) races
On 01/25/2013 08:25 AM, Al Viro wrote: > 1) process A does write() on efivars file, reaches ->get_variable(), > gets newdatasize set, drops efivars->lock and loses CPU before an attempt to > grab ->i_mutex. process B comes and does the same thing, replacing the > variable contents. Then it grabs ->i_mutex, updates size, drops ->i_mutex > and buggers off. At which point A gets CPU back and proceeds to set size > to whatever would be valid for its write. Only the value is bogus now... There are a few other things that makes size bogus now. 1. truncate() never touches nvram but pretends to be changing size. 2. Empty files come back with non-zero size after remount. They are imported from sysfs when mounting. 3. Arguably reading empty files could just return empty instead of returning EIO/EFI_NOT_FOUND from firmware. 4. EFI_VARIABLE_APPEND_WRITE with EFI_OUT_OF_RESOURCES truncates size but you can still read its content. -- 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/
boot warnings due to swap: make each swap partition have one address_space
Hi folks, Commit "swap: make each swap partition have one address_space" is triggering a series of warnings on boot: [3.446071] [ cut here ] [3.446664] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() [3.447715] ODEBUG: init active (active state 0) object type: percpu_counter hint: (null) [3.450360] Modules linked in: [3.451593] Pid: 1, comm: swapper/0 Tainted: GW 3.8.0-rc4-next-20130124-sasha-4-g838a1b4 #266 [3.454508] Call Trace: [3.455248] [] warn_slowpath_common+0x8c/0xc0 [3.455248] [] warn_slowpath_fmt+0x41/0x50 [3.455248] [] debug_print_object+0x8e/0xb0 [3.455248] [] __debug_object_init+0x20b/0x290 [3.455248] [] debug_object_init+0x15/0x20 [3.455248] [] __percpu_counter_init+0x6d/0xe0 [3.455248] [] bdi_init+0x1ac/0x270 [3.455248] [] swap_setup+0x3b/0x87 [3.455248] [] ? swap_setup+0x87/0x87 [3.455248] [] kswapd_init+0x11/0x7c [3.455248] [] do_one_initcall+0x8a/0x180 [3.455248] [] do_basic_setup+0x96/0xb4 [3.455248] [] ? loglevel+0x31/0x31 [3.455248] [] ? sched_init_smp+0x150/0x157 [3.455248] [] kernel_init_freeable+0xd2/0x14c [3.455248] [] ? rest_init+0x140/0x140 [3.455248] [] kernel_init+0x9/0xf0 [3.455248] [] ret_from_fork+0x7c/0xb0 [3.455248] [] ? rest_init+0x140/0x140 [3.455248] ---[ end trace 0b176d5c0f21bffb ]--- I haven't looked deeper into it yet, and will do so tomorrow, unless this spew is obvious to anyone. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: crash in ocfs2_fast_symlink_readpage in kernel 3.5.0
On Thu, Jan 24, 2013 at 2:30 PM, Andrew Morton wrote: > On Sat, 19 Jan 2013 20:15:33 -0800 > Bret Towe wrote: > >> > >> > it looks like you have a patch for this problem in a queue somewhere >> > (email found on ocfs2-dev: >> > https://oss.oracle.com/pipermail/ocfs2-devel/2012-August/008677.html ) >> > but its not in 3.6, any reason for the delay? >> > I've been running that patch on 3.5 for a while now likely since >> > around the time i found that email >> > and its been working well >> >> doesn't look to be in 3.7 or 3.8-git >> and from what i see on ocfs2-dev there are at least 16 other patches >> that are also being ignored? >> I'm sure if I'm bothering at this point to maintain my own patchset to >> keep ocfs2 from crashing >> that there is other folks doing the same > > Please resend all OCFS2 patches, cc'ing myself, Mark, Joel and > ocfs2-de...@oss.oracle.com. > > I shall then review them, merge them into -mm (and hence linux-next) so > they can get a bit of visibility and testing while the maintainers are > checking them over. > > Thanks. I've just been browsing the ocfs2-dev archives do you want me to pull them and resend or should i just link to the archive? keep in mind I'm just a end user not really a dev persay if you do want me to send the patches however I assume there is a document i should read first? -- 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] slub: assign refcount for kmalloc_caches
- Original Message - > From: "Greg Kroah-Hartman" > To: "Joonsoo Kim" > Cc: "Paul Hargrove" , "Pekka Enberg" > , linux-kernel@vger.kernel.org, > linux...@kvack.org, "Christoph Lameter" > Sent: Tuesday, January 15, 2013 3:23:36 AM > Subject: Re: [PATCH] slub: assign refcount for kmalloc_caches > > On Fri, Jan 11, 2013 at 04:52:54PM +0900, Joonsoo Kim wrote: > > On Thu, Jan 10, 2013 at 08:47:39PM -0800, Paul Hargrove wrote: > > > I just had a look at patch-3.7.2-rc1, and this change doesn't > > > appear to > > > have made it in yet. > > > Am I missing something? > > > > > > -Paul > > > > I try to check it. > > Ccing to Greg. > > > > Hello, Pekka and Greg. > > > > v3.8-rcX has already fixed by another stuff, but it is not simple > > change. > > So I made a new patch and sent it. > > > > How this kind of patch (only for stable v3.7) go into stable tree? > > through Pekka's slab tree? or send it to Greg, directly? > > > > I don't know how to submit this kind of patch to stable tree > > exactly. > > Could anyone help me? > > Please redo it, and send it to sta...@vger.kernel.org, and say > exactly > why it isn't in Linus's tree, and that it should only be applied to > 3.7-stable. I also met this during the testing, so I'll re-send it then. > > thanks, > > greg k-h > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 2/3] virtio-net: split out clean affinity function
On 01/21/2013 07:25 PM, Wanlong Gao wrote:
> Split out the clean affinity function to virtnet_clean_affinity().
>
> Cc: Rusty Russell
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Eric Dumazet
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Wanlong Gao
> ---
> V5->V6: NEW
>
> drivers/net/virtio_net.c | 67
> +++-
> 1 file changed, 38 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 70cd957..1a35a8c 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1016,48 +1016,57 @@ static int virtnet_vlan_rx_kill_vid(struct net_device
> *dev, u16 vid)
> return 0;
> }
>
> -static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
> +static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
> {
> int i;
> int cpu;
>
> - /* In multiqueue mode, when the number of cpu is equal to the number of
> - * queue pairs, we let the queue pairs to be private to one cpu by
> - * setting the affinity hint to eliminate the contention.
> - */
> - if ((vi->curr_queue_pairs == 1 ||
> - vi->max_queue_pairs != num_online_cpus()) && set) {
> - if (vi->affinity_hint_set)
> - set = false;
> - else
> - return;
> - }
> -
> - if (set) {
> - i = 0;
> - for_each_online_cpu(cpu) {
> - virtqueue_/set_affinity(vi->rq[i].vq, cpu);
> - virtqueue_set_affinity(vi->sq[i].vq, cpu);
> - *per_cpu_ptr(vi->vq_index, cpu) = i;
> - i++;
> - }
> -
> - vi->affinity_hint_set = true;
> - } else {
> - for(i = 0; i < vi->max_queue_pairs; i++) {
> + if (vi->affinity_hint_set) {
> + for (i = 0; i < vi->max_queue_pairs; i++) {
> virtqueue_set_affinity(vi->rq[i].vq, -1);
> virtqueue_set_affinity(vi->sq[i].vq, -1);
> }
>
> i = 0;
> - for_each_online_cpu(cpu)
> + for_each_online_cpu(cpu) {
> + if (cpu == hcpu)
> + continue;
> *per_cpu_ptr(vi->vq_index, cpu) =
> ++i % vi->curr_queue_pairs;
> + }
>
Some questions here:
- Did we need reset the affinity of the queue here like the this?
virtqueue_set_affinity(vi->sq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
virtqueue_set_affinity(vi->rq[*per_cpu_ptr(vi->vq_index, hcpu)], -1);
- Looks like we need also reset the percpu index when
vi->affinity_hint_set is false.
- Does this really need this reset? Consider we're going to reset the
percpu in CPU_DEAD?
Thanks
> vi->affinity_hint_set = false;
> }
> }
>
> +static void virtnet_set_affinity(struct virtnet_info *vi)
> +{
> + int i;
> + int cpu;
> +
> + /* In multiqueue mode, when the number of cpu is equal to the number of
> + * queue pairs, we let the queue pairs to be private to one cpu by
> + * setting the affinity hint to eliminate the contention.
> + */
> + if (vi->curr_queue_pairs == 1 ||
> + vi->max_queue_pairs != num_online_cpus()) {
> + if (vi->affinity_hint_set)
> + virtnet_clean_affinity(vi, -1);
> + else
> + return;
> + }
> +
> + i = 0;
> + for_each_online_cpu(cpu) {
> + virtqueue_set_affinity(vi->rq[i].vq, cpu);
> + virtqueue_set_affinity(vi->sq[i].vq, cpu);
> + *per_cpu_ptr(vi->vq_index, cpu) = i;
> + i++;
> + }
> +
> + vi->affinity_hint_set = true;
> +}
> +
> static void virtnet_get_ringparam(struct net_device *dev,
> struct ethtool_ringparam *ring)
> {
> @@ -1105,7 +1114,7 @@ static int virtnet_set_channels(struct net_device *dev,
> netif_set_real_num_rx_queues(dev, queue_pairs);
>
> get_online_cpus();
> - virtnet_set_affinity(vi, true);
> + virtnet_set_affinity(vi);
> put_online_cpus();
> }
>
> @@ -1274,7 +1283,7 @@ static void virtnet_del_vqs(struct virtnet_info *vi)
> {
> struct virtio_device *vdev = vi->vdev;
>
> - virtnet_set_affinity(vi, false);
> + virtnet_clean_affinity(vi, -1);
>
> vdev->config->del_vqs(vdev);
>
> @@ -1398,7 +1407,7 @@ static int init_vqs(struct virtnet_info *vi)
> goto err_free;
>
> get_online_cpus();
> - virtnet_set_affinity(vi, true);
> + virtnet_set_affinity(vi);
> put_online_cpus();
>
> 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
Re: [PATCH 0/2] kvm: IOMMU read-only mapping support
On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote: > On Thu, 24 Jan 2013 15:03:57 -0700 > Alex Williamson wrote: > >> A couple patches to make KVM IOMMU support honor read-only mappings. >> This causes an un-map, re-map when the read-only flag changes and >> makes use of it when setting IOMMU attributes. Thanks, > > Looks good to me. > > I think I can naturally update my patch after this gets merged. > Please wait. The commit c972f3b1 changed the write-protect behaviour - it does wirte-protection only when dirty flag is set. [ I did not see this commit when we discussed the problem before. ] Further more, i notice that write-protect is not enough, when do sync shadow page: FNAME(sync_page): host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE; set_spte(vcpu, >spt[i], pte_access, PT_PAGE_TABLE_LEVEL, gfn, spte_to_pfn(sp->spt[i]), true, false, host_writable); It sets spte based on the old value that means the readonly flag check is missed. We need to call kvm_arch_flush_shadow_all under this case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 1/3] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
On 01/21/2013 07:25 PM, Wanlong Gao wrote:
> As Michael mentioned, set affinity and select queue will not work very
> well when CPU IDs are not consecutive, this can happen with hot unplug.
> Fix this bug by traversal the online CPUs, and create a per cpu variable
> to find the mapping from CPU to the preferable virtual-queue.
>
> Cc: Rusty Russell
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Eric Dumazet
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Wanlong Gao
> ---
> V5->V6:
> remove {get|put}_online_cpus from virtnet_del_vqs (Jason)
> V4->V5:
> Add get/put_online_cpus to avoid CPUs go up and down during operations
> (Rusty)
>
> V3->V4:
> move vq_index into virtnet_info (Jason)
> change the mapping value when not setting affinity (Jason)
> address the comments about select_queue (Rusty)
>
> drivers/net/virtio_net.c | 58
> +++-
> 1 file changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index a6fcf15..70cd957 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -123,6 +123,9 @@ struct virtnet_info {
>
> /* Does the affinity hint is set for virtqueues? */
> bool affinity_hint_set;
> +
> + /* Per-cpu variable to show the mapping from CPU to virtqueue */
> + int __percpu *vq_index;
> };
>
> struct skb_vnet_hdr {
> @@ -1016,6 +1019,7 @@ static int virtnet_vlan_rx_kill_vid(struct net_device
> *dev, u16 vid)
> static void virtnet_set_affinity(struct virtnet_info *vi, bool set)
> {
> int i;
> + int cpu;
>
> /* In multiqueue mode, when the number of cpu is equal to the number of
>* queue pairs, we let the queue pairs to be private to one cpu by
> @@ -1029,16 +1033,29 @@ static void virtnet_set_affinity(struct virtnet_info
> *vi, bool set)
> return;
> }
>
> - for (i = 0; i < vi->max_queue_pairs; i++) {
> - int cpu = set ? i : -1;
> - virtqueue_set_affinity(vi->rq[i].vq, cpu);
> - virtqueue_set_affinity(vi->sq[i].vq, cpu);
> - }
> + if (set) {
> + i = 0;
> + for_each_online_cpu(cpu) {
> + virtqueue_set_affinity(vi->rq[i].vq, cpu);
> + virtqueue_set_affinity(vi->sq[i].vq, cpu);
> + *per_cpu_ptr(vi->vq_index, cpu) = i;
> + i++;
> + }
>
> - if (set)
> vi->affinity_hint_set = true;
> - else
> + } else {
> + for(i = 0; i < vi->max_queue_pairs; i++) {
> + virtqueue_set_affinity(vi->rq[i].vq, -1);
> + virtqueue_set_affinity(vi->sq[i].vq, -1);
> + }
> +
> + i = 0;
> + for_each_online_cpu(cpu)
> + *per_cpu_ptr(vi->vq_index, cpu) =
> + ++i % vi->curr_queue_pairs;
> +
> vi->affinity_hint_set = false;
> + }
> }
This looks wrong, since you always choose txq based on the per-cpu, I
think the per-cpu index should be set unconditionally even if cpus !=
queues. Consider you may boot a guest with 4 vcpus and 2 queues, you
need initialize it also in this case. Otherwise, you may always get txq
0 to be selected.
>
> static void virtnet_get_ringparam(struct net_device *dev,
> @@ -1087,7 +1104,9 @@ static int virtnet_set_channels(struct net_device *dev,
> netif_set_real_num_tx_queues(dev, queue_pairs);
> netif_set_real_num_rx_queues(dev, queue_pairs);
>
> + get_online_cpus();
> virtnet_set_affinity(vi, true);
> + put_online_cpus();
> }
>
> return err;
> @@ -1127,12 +1146,19 @@ static int virtnet_change_mtu(struct net_device *dev,
> int new_mtu)
>
> /* To avoid contending a lock hold by a vcpu who would exit to host, select
> the
> * txq based on the processor id.
> - * TODO: handle cpu hotplug.
> */
> static u16 virtnet_select_queue(struct net_device *dev, struct sk_buff *skb)
> {
> - int txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) :
> - smp_processor_id();
> + int txq;
> + struct virtnet_info *vi = netdev_priv(dev);
> +
> + if (skb_rx_queue_recorded(skb)) {
> + txq = skb_get_rx_queue(skb);
> + } else {
> + txq = *__this_cpu_ptr(vi->vq_index);
> + if (txq == -1)
> + txq = 0;
> + }
>
> while (unlikely(txq >= dev->real_num_tx_queues))
> txq -= dev->real_num_tx_queues;
> @@ -1371,7 +1397,10 @@ static int init_vqs(struct virtnet_info *vi)
> if (ret)
> goto err_free;
>
> + get_online_cpus();
> virtnet_set_affinity(vi, true);
> + put_online_cpus();
> +
> return 0;
>
> err_free:
> @@ -1453,6 +1482,10 @@ static int
Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
On Fri, Jan 25, 2013 at 12:14:54AM +, David Howells wrote: > You can't rely on someone trying to sneak a dodgy crypto module in to set the > flag when they build it. The detection thus needs to be done in the kernel > during the module load. > > Can you search the module image for "crypto_register_" I wonder? If that's > there, it's a crypto module. If you're trying to protect against malice rather than accident, what's going to stop the module from just finding and modifying data structures itself? If you want to panic if you've just loaded something that might compromise your crypto implementations, you've got to panic on all unsigned module loads. -- Matthew Garrett | mj...@srcf.ucam.org -- 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/6] ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data
Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index d149330..5f59bf2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -519,6 +519,20 @@
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp1";
+ usb2_phy: usb2phy@4a084000 {
+ compatible = "ti,omap-usb2";
+ reg = <0x4a084000 0x7c>;
+ ctrl_module = <_control_usb>;
+ };
+
+ usb3_phy: usb3phy@4a084400 {
+ compatible = "ti,omap-usb3";
+ reg = <0x4a084400 0x80>,
+ <0x4a084800 0x64>,
+ <0x4a084c00 0x40>;
+ reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+ ctrl_module = <_control_usb>;
+ };
};
};
};
--
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/
[PATCH 6/6] ARM: dts: palmas: update dt data for palmas-usb
Update palmas-usb data node in palmas device tree file
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/palmas.dtsi |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
index d20adb4..0cf39da 100644
--- a/arch/arm/boot/dts/palmas.dtsi
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -318,8 +318,8 @@
palmas_usb {
compatible = "ti,palmas-usb";
- ti,no_control_vbus = <0>;
- ti,wakeup = <0>;
+ ti,wakeup;
+ vbus-supply = <_reg>;
};
};
--
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/
[PATCH 2/6] ARM: dts: omap5: Add ocp2scp data
Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index edc7464..d149330 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -512,5 +512,13 @@
reg-names = "control_dev_conf", "phy_power_usb";
ti,type = <2>;
};
+
+ ocp2scp {
+ compatible = "ti,omap-ocp2scp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "ocp2scp1";
+ };
};
};
--
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/
[PATCH 0/6] ARM: dts: omap: add dt data for dwc3
This patch series adds dt data to get dwc3 working in omap5. This patch series is developed on git://github.com/rrnayak/linux.git omap5-3.8-rc4-base-palmas This is the last series of the series of patches. I've kept everything in a single branch git://gitorious.org/linux-usb/linux-usb.git omap5-with-palmas (changes up to 23b4dfa2ab7052569cd88acc6383c4b1a8e8a482) Did enumeration testing on omap5 evm. Kishon Vijay Abraham I (6): ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap dt data ARM: dts: omap5: add dwc3 core dt data ARM: dts: palmas: update dt data for palmas-usb arch/arm/boot/dts/omap5.dtsi | 48 + arch/arm/boot/dts/palmas.dtsi |4 ++-- 2 files changed, 50 insertions(+), 2 deletions(-) -- 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/
[PATCH 5/6] ARM: dts: omap5: add dwc3 core dt data
Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1703a72..58118c4 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -522,6 +522,13 @@
#size-cells = <1>;
utmi-mode = <2>;
ranges;
+ dwc3@4a03 {
+ compatible = "synopsys,dwc3";
+ reg = <0x4a03 0xcfff>;
+ interrupts = <0 92 4>;
+ usb_phy = <_phy>, <_phy>;
+ tx-fifo-resize;
+ };
};
ocp2scp {
--
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/
[PATCH 4/6] ARM: dts: omap5: add dwc3 omap dt data
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5f59bf2..1703a72 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,17 @@
ti,type = <2>;
};
+ omap_dwc3@4a02 {
+ compatible = "ti,dwc3";
+ ti,hwmods = "usb_otg_ss";
+ reg = <0x4a02 0x1ff>;
+ interrupts = <0 93 4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <2>;
+ ranges;
+ };
+
ocp2scp {
compatible = "ti,omap-ocp2scp";
#address-cells = <1>;
--
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/
[PATCH 1/6] ARM: dts: omap5: Add omap control usb data
Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7a78d1b..edc7464 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -504,5 +504,13 @@
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = "ti,omap-control-usb";
+ reg = <0x4a002300 0x4>,
+ <0x4a002370 0x4>;
+ reg-names = "control_dev_conf", "phy_power_usb";
+ ti,type = <2>;
+ };
};
};
--
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/
[PATCH v1 2/8] usb: otg: palmas-usb: use devres API to allocate resources
used devres API while allocating resources so that these resources are
released automatically on driver detach.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/palmas-usb.c | 47 ++
1 file changed, 15 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index 76240ef..f063350 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -278,7 +278,7 @@ static int palmas_usb_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
- palmas_usb = kzalloc(sizeof(*palmas_usb), GFP_KERNEL);
+ palmas_usb = devm_kzalloc(>dev, sizeof(*palmas_usb), GFP_KERNEL);
if (!palmas_usb)
return -ENOMEM;
@@ -311,11 +311,10 @@ static int palmas_usb_probe(struct platform_device *pdev)
spin_lock_init(_usb->lock);
if (!pdata->no_control_vbus) {
- palmas_usb->vbus_reg = regulator_get(palmas->dev,
+ palmas_usb->vbus_reg = devm_regulator_get(palmas->dev,
"vbus");
if (IS_ERR(palmas_usb->vbus_reg)) {
dev_err(>dev, "vbus init failed\n");
- kfree(palmas_usb);
return PTR_ERR(palmas_usb->vbus_reg);
}
}
@@ -330,44 +329,44 @@ static int palmas_usb_probe(struct platform_device *pdev)
INIT_WORK(_usb->set_vbus_work, palmas_set_vbus_work);
- status = request_threaded_irq(palmas_usb->irq1, NULL,
- palmas_id_irq,
+ status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq1,
+ NULL, palmas_id_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"palmas_usb", palmas_usb);
if (status < 0) {
dev_err(>dev, "can't get IRQ %d, err %d\n",
palmas_usb->irq1, status);
- goto fail_irq1;
+ goto fail_irq;
}
- status = request_threaded_irq(palmas_usb->irq2, NULL,
- palmas_id_wakeup_irq,
+ status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq2,
+ NULL, palmas_id_wakeup_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"palmas_usb", palmas_usb);
if (status < 0) {
dev_err(>dev, "can't get IRQ %d, err %d\n",
palmas_usb->irq2, status);
- goto fail_irq2;
+ goto fail_irq;
}
- status = request_threaded_irq(palmas_usb->irq3, NULL,
- palmas_vbus_irq,
+ status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq3,
+ NULL, palmas_vbus_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"palmas_usb", palmas_usb);
if (status < 0) {
dev_err(>dev, "can't get IRQ %d, err %d\n",
palmas_usb->irq3, status);
- goto fail_irq3;
+ goto fail_irq;
}
- status = request_threaded_irq(palmas_usb->irq4, NULL,
- palmas_vbus_wakeup_irq,
+ status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq4,
+ NULL, palmas_vbus_wakeup_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"palmas_usb", palmas_usb);
if (status < 0) {
dev_err(>dev, "can't get IRQ %d, err %d\n",
palmas_usb->irq4, status);
- goto fail_irq4;
+ goto fail_irq;
}
dev_info(>dev, "Initialized Palmas USB module\n");
@@ -376,19 +375,9 @@ static int palmas_usb_probe(struct platform_device *pdev)
return 0;
-fail_irq4:
- free_irq(palmas_usb->irq3, palmas_usb);
-
-fail_irq3:
- free_irq(palmas_usb->irq2, palmas_usb);
-
-fail_irq2:
- free_irq(palmas_usb->irq1, palmas_usb);
-
-fail_irq1:
+fail_irq:
cancel_work_sync(_usb->set_vbus_work);
device_remove_file(palmas_usb->dev, _attr_vbus);
- kfree(palmas_usb);
return status;
}
@@ -397,14 +386,8 @@ static int palmas_usb_remove(struct platform_device *pdev)
{
struct palmas_usb *palmas_usb = platform_get_drvdata(pdev);
- free_irq(palmas_usb->irq1, palmas_usb);
- free_irq(palmas_usb->irq2, palmas_usb);
- free_irq(palmas_usb->irq3, palmas_usb);
- free_irq(palmas_usb->irq4, palmas_usb);
- regulator_put(palmas_usb->vbus_reg);
device_remove_file(palmas_usb->dev, _attr_vbus);
cancel_work_sync(_usb->set_vbus_work);
- kfree(palmas_usb);
return 0;
}
--
1.7.9.5
--
To
[PATCH v1 5/8] usb: otg: palmas-usb: use bool to read property instead of u32
properies like wakeup and no_control_vbus can be represented in boolean,
so read those properties using of_property_read_bool.
Also updated the documentation with device tree binding information for
palmas-usb.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/usb/twl-usb.txt| 24
drivers/usb/otg/palmas-usb.c | 15 +++-
2 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 36b9aed..fa037ad 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -38,3 +38,27 @@ twl4030-usb {
usb3v1-supply = <>;
usb_mode = <1>;
};
+
+PALMAS USB COMPARATOR
+Required Properties:
+ - compatible : Should be "ti,palmas-usb"
+ - interrupts : Four interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ ID wakeup interrupt number, third interrupt is VBUS interrupt and fourth
+ interrupt is VBUS wakeup interrupt.
+- interrupt-name : the name corresponding to each interrupt populated in
+ interrupts property.
+ - vbus-supply : phandle to the regulator device tree node.
+
+Optional Properties:
+ - ti,wakeup : To enable the wakeup comparator in probe
+ - ti,no_control_vbus: if the platform wishes its own vbus control
+
+palmas-usb {
+ compatible = "ti,palmas-usb";
+ interrupts = <20 0>, <21 0>, <22 0>, <23 0>;
+ interrupt-names = "ID", "ID_WAKEUP", "VBUS", "VBUS_WAKEUP";
+ vbus-supply = <_reg>;
+ ti,wakeup;
+};
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index 1bd8b15..2377836 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -235,18 +235,9 @@ static int palmas_start_srp(struct phy_companion
*comparator)
static void palmas_dt_to_pdata(struct device_node *node,
struct palmas_usb_platform_data *pdata)
{
- int ret;
- u32 prop;
-
- ret = of_property_read_u32(node, "ti,no_control_vbus", );
- if (!ret) {
- pdata->no_control_vbus = prop;
- }
-
- ret = of_property_read_u32(node, "ti,wakeup", );
- if (!ret) {
- pdata->wakeup = prop;
- }
+ pdata->no_control_vbus = of_property_read_bool(node,
+ "ti,no_control_vbus");
+ pdata->wakeup = of_property_read_bool(node, "ti,wakeup");
}
static int palmas_usb_probe(struct platform_device *pdev)
--
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/
[PATCH v1 4/8] usb: otg: palmas-usb: use mailbox API to send VBUS or ID events
Whenever palmas detects a VBUS or ID event, the mailbox API in dwc3 glue
is called. The mailbox API takes care of notifying it to the core.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Moiz Sonasath
---
drivers/usb/otg/palmas-usb.c | 32 +---
include/linux/mfd/palmas.h |4 +++-
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index be9d81c..1bd8b15 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -85,13 +86,14 @@ static ssize_t palmas_usb_vbus_show(struct device *dev,
spin_lock_irqsave(_usb->lock, flags);
switch (palmas_usb->linkstat) {
- case USB_EVENT_VBUS:
+ case OMAP_DWC3_VBUS_VALID:
ret = snprintf(buf, PAGE_SIZE, "vbus\n");
break;
- case USB_EVENT_ID:
+ case OMAP_DWC3_ID_GROUND:
ret = snprintf(buf, PAGE_SIZE, "id\n");
break;
- case USB_EVENT_NONE:
+ case OMAP_DWC3_ID_FLOAT:
+ case OMAP_DWC3_VBUS_OFF:
ret = snprintf(buf, PAGE_SIZE, "none\n");
break;
default:
@@ -106,7 +108,7 @@ static DEVICE_ATTR(vbus, 0444, palmas_usb_vbus_show, NULL);
static irqreturn_t palmas_vbus_wakeup_irq(int irq, void *_palmas_usb)
{
struct palmas_usb *palmas_usb = _palmas_usb;
- int status = 0;
+ enum omap_dwc3_vbus_id_status status = OMAP_DWC3_UNKNOWN;
int slave;
unsigned int vbus_line_state, addr;
@@ -118,20 +120,24 @@ static irqreturn_t palmas_vbus_wakeup_irq(int irq, void
*_palmas_usb)
if (vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS) {
regulator_enable(palmas_usb->vbus_reg);
- status = USB_EVENT_VBUS;
+ status = OMAP_DWC3_VBUS_VALID;
} else {
- status = USB_EVENT_NONE;
+ status = OMAP_DWC3_VBUS_OFF;
regulator_disable(palmas_usb->vbus_reg);
}
palmas_usb->linkstat = status;
+ if (status != OMAP_DWC3_UNKNOWN) {
+ dwc3_omap_mailbox(status);
+ return IRQ_HANDLED;
+ }
- return IRQ_HANDLED;
+ return IRQ_NONE;
}
static irqreturn_t palmas_id_wakeup_irq(int irq, void *_palmas_usb)
{
- int status = 0;
+ enum omap_dwc3_vbus_id_status status = OMAP_DWC3_UNKNOWN;
unsigned intset;
struct palmas_usb *palmas_usb = _palmas_usb;
@@ -145,7 +151,7 @@ static irqreturn_t palmas_id_wakeup_irq(int irq, void
*_palmas_usb)
palmas_usb_write(palmas_usb->palmas,
PALMAS_USB_ID_INT_EN_HI_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
- status = USB_EVENT_ID;
+ status = OMAP_DWC3_ID_GROUND;
} else if (set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) {
palmas_usb_write(palmas_usb->palmas,
PALMAS_USB_ID_INT_EN_HI_SET,
@@ -154,12 +160,16 @@ static irqreturn_t palmas_id_wakeup_irq(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_EN_HI_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
regulator_disable(palmas_usb->vbus_reg);
- status = USB_EVENT_NONE;
+ status = OMAP_DWC3_ID_FLOAT;
}
palmas_usb->linkstat = status;
+ if (status != OMAP_DWC3_UNKNOWN) {
+ dwc3_omap_mailbox(status);
+ return IRQ_HANDLED;
+ }
- return IRQ_HANDLED;
+ return IRQ_NONE;
}
static int palmas_enable_irq(struct palmas_usb *palmas_usb)
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index a557db6..d6c3bec 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#define PALMAS_NUM_CLIENTS 3
@@ -361,7 +363,7 @@ struct palmas_usb {
int vbus_enable;
- u8 linkstat;
+ enum omap_dwc3_vbus_id_status linkstat;
};
#define comparator_to_palmas(x) container_of((x), struct palmas_usb,
comparator)
--
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/
[PATCH v1 8/8] usb: otg: palmas-usb: fix cold plug issue
if the cable is connected even before the palmas-usb is loaded, the cable connect detection event will be missed. It's fixed here by checking for VBUS line states when palmas-usb is loaded. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/otg/palmas-usb.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c index 07629cd..d62f673 100644 --- a/drivers/usb/otg/palmas-usb.c +++ b/drivers/usb/otg/palmas-usb.c @@ -187,6 +187,11 @@ static int palmas_enable_irq(struct palmas_usb *palmas_usb) palmas_usb_write(palmas_usb->palmas, PALMAS_USB_ID_INT_EN_HI_SET, PALMAS_USB_ID_INT_EN_HI_SET_ID_GND); + palmas_vbus_wakeup_irq(palmas_usb->irq4, palmas_usb); + + if (palmas_usb->linkstat == OMAP_DWC3_UNKNOWN) + palmas_id_wakeup_irq(palmas_usb->irq2, palmas_usb); + return 0; } -- 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: [GIT PULL] Btrfs fixes
On Thu, Jan 24, 2013 at 1:52 PM, Chris Mason wrote: > > Update on this, we've tracked down the crc errors and are doing final > checks on the patches. Linus are you planning on taking this pull? If > not I can just fold the new stuff into a bigger request. If you have them basically ready, add them to this, I haven't pulled yet. So I'll just ignore this and wait for another pull request. 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/
[PATCH v1 7/8] usb: otg: palmas-usb: pass the correct dev ptr in regulator get
regulator_get is passing the device pointer of the parent (palmas)
instead of the child (palmas-usb). It's been fixed here.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/palmas-usb.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index 442f09c..07629cd 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -303,8 +303,7 @@ static int palmas_usb_probe(struct platform_device *pdev)
spin_lock_init(_usb->lock);
if (!pdata->no_control_vbus) {
- palmas_usb->vbus_reg = devm_regulator_get(palmas->dev,
- "vbus");
+ palmas_usb->vbus_reg = devm_regulator_get(>dev, "vbus");
if (IS_ERR(palmas_usb->vbus_reg)) {
dev_err(>dev, "vbus init failed\n");
return PTR_ERR(palmas_usb->vbus_reg);
--
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/
[PATCH v1 1/8] usb: otg: palmas-usb: make palmas-usb as a comparator driver
palmas-usb is made as a comparator driver to omap usb2 phy, so that
omap usb can make use of palmas for srp and also to set vbus.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/palmas-usb.c | 20 ++--
include/linux/mfd/palmas.h |3 +++
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index 8389ad6..76240ef 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -31,6 +31,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -208,16 +210,20 @@ static void palmas_set_vbus_work(struct work_struct *data)
regulator_disable(palmas_usb->vbus_reg);
}
-static int palmas_set_vbus(struct palmas_usb *palmas_usb, bool enabled)
+static int palmas_set_vbus(struct phy_companion *comparator, bool enabled)
{
+ struct palmas_usb *palmas_usb = comparator_to_palmas(comparator);
+
palmas_usb->vbus_enable = enabled;
schedule_work(_usb->set_vbus_work);
return 0;
}
-static int palmas_start_srp(struct palmas_usb *palmas_usb)
+static int palmas_start_srp(struct phy_companion *comparator)
{
+ struct palmas_usb *palmas_usb = comparator_to_palmas(comparator);
+
palmas_usb_write(palmas_usb->palmas, PALMAS_USB_VBUS_CTRL_SET,
PALMAS_USB_VBUS_CTRL_SET_VBUS_DISCHRG |
PALMAS_USB_VBUS_CTRL_SET_VBUS_IADP_SINK);
@@ -253,6 +259,7 @@ static void palmas_dt_to_pdata(struct device_node *node,
static int palmas_usb_probe(struct platform_device *pdev)
{
+ u32 ret;
struct palmas *palmas = dev_get_drvdata(pdev->dev.parent);
struct palmas_usb_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
@@ -289,6 +296,15 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_usb->irq4 = regmap_irq_get_virq(palmas->irq_data,
PALMAS_VBUS_IRQ);
+ palmas_usb->comparator.set_vbus = palmas_set_vbus;
+ palmas_usb->comparator.start_srp = palmas_start_srp;
+
+ ret = omap_usb2_set_comparator(_usb->comparator);
+ if (ret == -ENODEV) {
+ dev_info(>dev, "phy not ready, deferring probe");
+ return -EPROBE_DEFER;
+ }
+
palmas_usb_wakeup(palmas, pdata->wakeup);
/* init spinlock for workqueue */
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 82932db..a557db6 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define PALMAS_NUM_CLIENTS 3
@@ -343,6 +344,8 @@ struct palmas_usb {
struct palmas *palmas;
struct device *dev;
+ struct phy_companion comparator;
+
/* for vbus reporting with irqs disabled */
spinlock_t lock;
--
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/
[PATCH v1 6/8] usb: otg: palmas-usb: call regulator enable/disable only on valid regulator
The calls to regulator enable/disable was done unconditionally which
might result in warn dumps if *no_control_vbus* is set. So always call
regulator enable/disable on valid regulator.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/palmas-usb.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index 2377836..442f09c 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -119,11 +119,13 @@ static irqreturn_t palmas_vbus_wakeup_irq(int irq, void
*_palmas_usb)
regmap_read(palmas_usb->palmas->regmap[slave], addr, _line_state);
if (vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS) {
- regulator_enable(palmas_usb->vbus_reg);
+ if (!IS_ERR_OR_NULL(palmas_usb->vbus_reg))
+ regulator_enable(palmas_usb->vbus_reg);
status = OMAP_DWC3_VBUS_VALID;
} else {
status = OMAP_DWC3_VBUS_OFF;
- regulator_disable(palmas_usb->vbus_reg);
+ if (!IS_ERR_OR_NULL(palmas_usb->vbus_reg))
+ regulator_disable(palmas_usb->vbus_reg);
}
palmas_usb->linkstat = status;
@@ -144,7 +146,8 @@ static irqreturn_t palmas_id_wakeup_irq(int irq, void
*_palmas_usb)
palmas_usb_read(palmas_usb->palmas, PALMAS_USB_ID_INT_LATCH_SET, );
if (set & PALMAS_USB_ID_INT_SRC_ID_GND) {
- regulator_enable(palmas_usb->vbus_reg);
+ if (!IS_ERR_OR_NULL(palmas_usb->vbus_reg))
+ regulator_enable(palmas_usb->vbus_reg);
palmas_usb_write(palmas_usb->palmas,
PALMAS_USB_ID_INT_EN_HI_SET,
PALMAS_USB_ID_INT_EN_HI_SET_ID_FLOAT);
@@ -159,7 +162,8 @@ static irqreturn_t palmas_id_wakeup_irq(int irq, void
*_palmas_usb)
palmas_usb_write(palmas_usb->palmas,
PALMAS_USB_ID_INT_EN_HI_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
- regulator_disable(palmas_usb->vbus_reg);
+ if (!IS_ERR_OR_NULL(palmas_usb->vbus_reg))
+ regulator_disable(palmas_usb->vbus_reg);
status = OMAP_DWC3_ID_FLOAT;
}
@@ -191,6 +195,11 @@ static void palmas_set_vbus_work(struct work_struct *data)
struct palmas_usb *palmas_usb = container_of(data, struct palmas_usb,
set_vbus_work);
+ if (IS_ERR_OR_NULL(palmas_usb->vbus_reg)) {
+ dev_err(palmas_usb->dev, "invalid regulator\n");
+ return;
+ }
+
/*
* Start driving VBUS. Set OPA_MODE bit in CHARGERUSB_CTRL1
* register. This enables boost mode.
--
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/
[PATCH v1 3/8] usb: otg: palmas-usb: remove compiler warning
commit 696c5c04 (USB: Palmas OTG Transceiver Driver) introduced empty
palmas_vbus_irq/palmas_id_irq with only *palmas_usb* declaration.
Removed these unnecessary functions.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/palmas-usb.c | 38 --
1 file changed, 38 deletions(-)
diff --git a/drivers/usb/otg/palmas-usb.c b/drivers/usb/otg/palmas-usb.c
index f063350..be9d81c 100644
--- a/drivers/usb/otg/palmas-usb.c
+++ b/drivers/usb/otg/palmas-usb.c
@@ -103,15 +103,6 @@ static ssize_t palmas_usb_vbus_show(struct device *dev,
}
static DEVICE_ATTR(vbus, 0444, palmas_usb_vbus_show, NULL);
-static irqreturn_t palmas_vbus_irq(int irq, void *_palmas_usb)
-{
- struct palmas_usb *palmas_usb = _palmas_usb;
-
- /* TODO: Do we need to do any work here? */
-
- return IRQ_HANDLED;
-}
-
static irqreturn_t palmas_vbus_wakeup_irq(int irq, void *_palmas_usb)
{
struct palmas_usb *palmas_usb = _palmas_usb;
@@ -138,15 +129,6 @@ static irqreturn_t palmas_vbus_wakeup_irq(int irq, void
*_palmas_usb)
return IRQ_HANDLED;
}
-static irqreturn_t palmas_id_irq(int irq, void *_palmas_usb)
-{
- struct palmas_usb *palmas_usb = _palmas_usb;
-
- /* TODO: Do we need to do any work here? */
-
- return IRQ_HANDLED;
-}
-
static irqreturn_t palmas_id_wakeup_irq(int irq, void *_palmas_usb)
{
int status = 0;
@@ -329,16 +311,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
INIT_WORK(_usb->set_vbus_work, palmas_set_vbus_work);
- status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq1,
- NULL, palmas_id_irq,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
- "palmas_usb", palmas_usb);
- if (status < 0) {
- dev_err(>dev, "can't get IRQ %d, err %d\n",
- palmas_usb->irq1, status);
- goto fail_irq;
- }
-
status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq2,
NULL, palmas_id_wakeup_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
@@ -349,16 +321,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
goto fail_irq;
}
- status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq3,
- NULL, palmas_vbus_irq,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
- "palmas_usb", palmas_usb);
- if (status < 0) {
- dev_err(>dev, "can't get IRQ %d, err %d\n",
- palmas_usb->irq3, status);
- goto fail_irq;
- }
-
status = devm_request_threaded_irq(palmas_usb->dev, palmas_usb->irq4,
NULL, palmas_vbus_wakeup_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
--
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/
[PATCH v1 0/8] usb: otg: palmas-usb: fixes/cleanups to get dwc3 working
This includes a series of patches that should be used for testing dwc3 in omap5. Among other changes, palmas is made as a comparator driver to the phy. And includes a fix to get a regulator by having phandle. This patch series is developed on git://github.com/rrnayak/linux.git omap5-3.8-rc4-base-palmas I've kept this patch series and the patch series to follow in a single branch git://gitorious.org/linux-usb/linux-usb.git omap5-with-palmas (changes up to 23b4dfa2ab7052569cd88acc6383c4b1a8e8a482) Did enumeration testing on omap5 evm. Kishon Vijay Abraham I (8): usb: otg: palmas-usb: make palmas-usb as a comparator driver usb: otg: palmas-usb: use devres API to allocate resources usb: otg: palmas-usb: remove compiler warning usb: otg: palmas-usb: use mailbox API to send VBUS or ID events usb: otg: palmas-usb: use bool to read property instead of u32 usb: otg: palmas-usb: call regulator enable/disable only on valid regulator usb: otg: palmas-usb: pass the correct dev ptr in regulator get usb: otg: palmas-usb: fix cold plug issue .../devicetree/bindings/usb/twl-usb.txt| 24 +++ drivers/usb/otg/palmas-usb.c | 163 +--- include/linux/mfd/palmas.h |7 +- 3 files changed, 99 insertions(+), 95 deletions(-) -- 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: [PATCH] firmware: Make user-mode helper optional
On Tue, Jan 22, 2013 at 7:51 PM, Takashi Iwai wrote:
> Since 3.7 kernel, the firmware loader can read the firmware files
> directly, and the traditional user-mode helper is invoked only as a
> fallback. This seems working pretty well, and the next step would be
> to reduce the redundant user-mode helper stuff in future.
The idea is good.
>
> This patch is a preparation for that, to make the user-mode helper
> invocation optional via kconfig. Other than that, there is no
> functional change here.
In fact, your patch does much code refactoring work, which isn't
strictly related with what you claimed in the commit log, at least
it should be separated from introducing FW_LOADER_USER_HELPER.
So could you split the patch into several parts and let one part do one thing
so that we can review them a bit easily?
Also it is not good to introduce too many '#ifdef #endif', IMO.
>
> Signed-off-by: Takashi Iwai
> ---
> drivers/base/Kconfig | 11 ++
> drivers/base/firmware_class.c | 350
> +-
> 2 files changed, 218 insertions(+), 143 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index c8b4539..07abd9d 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -145,6 +145,17 @@ config EXTRA_FIRMWARE_DIR
> this option you can point it elsewhere, such as /lib/firmware/ or
> some other directory containing the firmware files.
>
> +config FW_LOADER_USER_HELPER
> + bool "Fallback user-helper invocation for firmware loading"
> + depends on FW_LOADER
> + default y
> + help
> + This option enables / disables the invocation of user-helper
> + (e.g. udev) for loading firmware files as a fallback after the
> + direct file loading in kernel fails. The user-mode helper is
> + no longer required unless you have a special firmware file that
> + resides in a non-standard path.
> +
> config DEBUG_DRIVER
> bool "Driver Core verbose debug messages"
> depends on DEBUG_KERNEL
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index b392b35..6c6f714 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -88,6 +88,7 @@ enum {
> FW_STATUS_ABORT,
> };
>
> +#ifdef CONFIG_FW_LOADER_USER_HELPER
> enum fw_buf_fmt {
> VMALLOC_BUF,/* used in direct loading */
> PAGE_BUF, /* used in loading via userspace */
> @@ -99,6 +100,7 @@ static inline long firmware_loading_timeout(void)
> {
> return loading_timeout > 0 ? loading_timeout * HZ :
> MAX_SCHEDULE_TIMEOUT;
> }
> +#endif /* CONFIG_FW_LOADER_USER_HELPER */
>
> struct firmware_cache {
> /* firmware_buf instance will be added into the below list */
> @@ -128,12 +130,14 @@ struct firmware_buf {
> struct completion completion;
> struct firmware_cache *fwc;
> unsigned long status;
> - enum fw_buf_fmt fmt;
> void *data;
> size_t size;
> +#ifdef CONFIG_FW_LOADER_USER_HELPER
> + enum fw_buf_fmt fmt;
> struct page **pages;
> int nr_pages;
> int page_array_size;
> +#endif
> char fw_id[];
> };
>
> @@ -142,6 +146,7 @@ struct fw_cache_entry {
> char name[];
> };
>
> +#ifdef CONFIG_FW_LOADER_USER_HELPER
> struct firmware_priv {
> struct delayed_work timeout_work;
> bool nowait;
> @@ -149,6 +154,7 @@ struct firmware_priv {
> struct firmware_buf *buf;
> struct firmware *fw;
> };
> +#endif
>
> struct fw_name_devm {
> unsigned long magic;
> @@ -182,7 +188,9 @@ static struct firmware_buf *__allocate_fw_buf(const char
> *fw_name,
> strcpy(buf->fw_id, fw_name);
> buf->fwc = fwc;
> init_completion(>completion);
> +#ifdef CONFIG_FW_LOADER_USER_HELPER
> buf->fmt = VMALLOC_BUF;
> +#endif
>
> pr_debug("%s: fw-%s buf=%p\n", __func__, fw_name, buf);
>
> @@ -240,7 +248,6 @@ static void __fw_free_buf(struct kref *ref)
> {
> struct firmware_buf *buf = to_fwbuf(ref);
> struct firmware_cache *fwc = buf->fwc;
> - int i;
>
> pr_debug("%s: fw-%s buf=%p data=%p size=%u\n",
> __func__, buf->fw_id, buf, buf->data,
> @@ -250,12 +257,15 @@ static void __fw_free_buf(struct kref *ref)
> spin_unlock(>lock);
>
>
> +#ifdef CONFIG_FW_LOADER_USER_HELPER
> if (buf->fmt == PAGE_BUF) {
> + int i;
> vunmap(buf->data);
> for (i = 0; i < buf->nr_pages; i++)
> __free_page(buf->pages[i]);
> kfree(buf->pages);
> } else
> +#endif
> vfree(buf->data);
> kfree(buf);
> }
> @@ -319,7 +329,8 @@ static bool fw_read_file_contents(struct file *file,
> struct firmware_buf *fw_buf
> return true;
> }
>
> -static bool fw_get_filesystem_firmware(struct firmware_buf *buf)
> +static bool
Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
Kyle McMartin writes: > After thinking about it a while, this seems like the best way to solve > the problem, although it does still kind of offend my delicate > sensibilities... You're far too polite. This patch was horrible, partial and ugly. Stephan Mueller wrote: > FIPS requires the module (in our case the static kernel binary with its > kernel crypto API plus all the crypto kernel modules) to be unavailable > if the module signature fails. That is an unconditional requirement. "the module signature" here being the signature of any crypto module, I'm guessing from Kyle's awful patch. Any crypto module, or just some? Presumably any module used by any crypto module, too? Because you can panic when a !sig_ok module registers a crypto algorithm. Or you can panic when anyone registers a crypto algorithm after any module has failed the signature check. But it doesn't make much sense to pick on the crypto modules, since they're not well isolated from the rest of the kernel. Thanks, Rusty. -- 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 02/11] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
Used of_platform_populate() to create dwc3 core platform_device
from device tree data.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 40 ++--
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 1d03a8a..78bb2f6 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
@@ -133,7 +134,6 @@ struct dwc3_omap {
/* device lock */
spinlock_t lock;
- struct platform_device *dwc3;
struct platform_device *usb2_phy;
struct platform_device *usb3_phy;
struct device *dev;
@@ -276,7 +276,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
struct dwc3_omap_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
- struct platform_device *dwc3;
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = >dev;
@@ -323,30 +322,19 @@ static int dwc3_omap_probe(struct platform_device *pdev)
return ret;
}
- dwc3 = platform_device_alloc("dwc3", PLATFORM_DEVID_AUTO);
- if (!dwc3) {
- dev_err(dev, "couldn't allocate dwc3 device\n");
- return -ENOMEM;
- }
-
context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
if (!context) {
dev_err(dev, "couldn't allocate dwc3 context memory\n");
- goto err2;
+ return -ENOMEM;
}
spin_lock_init(>lock);
- dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
- dwc3->dev.parent = dev;
- dwc3->dev.dma_mask = dev->dma_mask;
- dwc3->dev.dma_parms = dev->dma_parms;
omap->resource_size = resource_size(res);
omap->context = context;
omap->dev = dev;
omap->irq = irq;
omap->base = base;
- omap->dwc3 = dwc3;
reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
@@ -391,7 +379,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
- goto err2;
+ return ret;
}
/* enable all IRQs */
@@ -410,24 +398,16 @@ static int dwc3_omap_probe(struct platform_device *pdev)
dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_SET_1, reg);
- ret = platform_device_add_resources(dwc3, pdev->resource,
- pdev->num_resources);
- if (ret) {
- dev_err(dev, "couldn't add resources to dwc3 device\n");
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, "failed to register dwc3 device\n");
- goto err2;
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(>dev,
+ "failed to add create dwc3 core\n");
+ return ret;
+ }
}
return 0;
-
-err2:
- platform_device_put(dwc3);
- return ret;
}
static int dwc3_omap_remove(struct platform_device *pdev)
--
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/
[PATCH v3 11/11] usb: dwc3: core: stray statements are removed
No functional change. Stray statements where removed from dwc3 core.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/core.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index af189d5..ee1fa18 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -558,9 +558,6 @@ err0:
static int dwc3_remove(struct platform_device *pdev)
{
struct dwc3 *dwc = platform_get_drvdata(pdev);
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
usb_phy_set_suspend(dwc->usb2_phy, 1);
usb_phy_set_suspend(dwc->usb3_phy, 1);
--
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/
[PATCH v3 10/11] usb: dwc3: core: enable the USB2 and USB3 phy in probe
Enabled the USB2 and USB3 PHY in probe by calling usb_phy_set_suspend and disabled the PHYs on driver removal. When PM is implemented this will be optimized to enable the PHYs only when needed. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/dwc3/core.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index c1fb6d2..af189d5 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -438,6 +438,9 @@ static int dwc3_probe(struct platform_device *pdev) return -EPROBE_DEFER; } + usb_phy_set_suspend(dwc->usb2_phy, 0); + usb_phy_set_suspend(dwc->usb3_phy, 0); + spin_lock_init(>lock); platform_set_drvdata(pdev, dwc); @@ -559,6 +562,9 @@ static int dwc3_remove(struct platform_device *pdev) res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + usb_phy_set_suspend(dwc->usb2_phy, 1); + usb_phy_set_suspend(dwc->usb3_phy, 1); + pm_runtime_put(>dev); pm_runtime_disable(>dev); -- 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/
