Re: [PATCH 1/1] sbs-battery: Use of_match_ptr() macro
On Mon, Apr 01, 2013 at 09:02:28AM +0530, Sachin Kamat wrote: [...] > > - .of_match_table = sbs_dt_ids, > > + .of_match_table = of_match_ptr(sbs_dt_ids), > > }, > > }; > > module_i2c_driver(sbs_battery_driver); > > -- > > 1.7.4.1 > > ping... Applied, thanks! Anton -- 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] intel-iommu: Synchronize gcmd value with global command register
(2013/03/27 19:31), Joerg Roedel wrote: > On Wed, Mar 27, 2013 at 02:02:44PM +0900, Takao Indoh wrote: >> The root cause of this problem is mismatch between iommu->gcmd and >> global command register in the case of kdump. At boot time, initial >> value of iommu->gcmd is zero as I wrote above, but actual global command >> register is *not* zero because some bits like IRE/TE/QIE are already set >> in *first* kernel. Therefore this patch synchronize them to fix this >> problem. > > Ok, I understand, but I still don't see why this is a problem. There is > no point for the kdump kernel to preserve hardware state from the > previous kernel. So I think the way it is implemented is correct. Sorry, my explanation was misleading. The purpose is not preserving hardware state, but cleaning up hardware status at appropriate place. kdump kernel boots up without power-on-reset, so we have to disable hardware functions like DMAR before initializing them. enable_IR intel_enable_irq_remapping iommu_disable_irq_remapping <== IRES/QIES/TES disabled here dmar_disable_qi <== do nothing dmar_enable_qi <== QIES enabled intel_setup_irq_remapping<== IRES enabled intel_iommu_init init_dmars iommu_enable_translation <== TES enabled enable_IR intel_enable_irq_remapping iommu_disable_irq_remapping <== IRES disabled dmar_disable_qi <== QIES disabled dmar_enable_qi <== QIES enabled intel_setup_irq_remapping<== IRES enabled intel_iommu_init init_dmars iommu_disable_translation<== TES disabled (added by patch) iommu_enable_translation <== TES enabled I want to change flow like this to avoid misunderstanding. In that sense, this patch is a kind of cleanup rather than fixing problem. Backgroud: I'm working on kdump problem with iommu and investigated when DMAR and IR are disabled in kdump kernel boot. As for IR, I can easily find the code in intel_enable_irq_remapping() since there is good comment for that. /* * Disable intr remapping and queued invalidation, if already * enabled prior to OS handover. */ iommu_disable_irq_remapping(iommu); dmar_disable_qi(iommu); However, there is no code to disable DMAR on startup, but it is actually disabled somewhere during bootup. And finally I found out is is done in intel_enable_irq_remapping(). This is very misleading. Why "iommu_disable_irq_remapping" is disabling bits other than IR? After applying patch, it is easy to understand because it disables only IR, as the name suggests. Thanks, Takao Indoh -- 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] mm, memcg: give exiting processes access to memory reserves
(2013/03/28 10:22), David Rientjes wrote:
A memcg may livelock when oom if the process that grabs the hierarchy's
oom lock is never the first process with PF_EXITING set in the memcg's
task iteration.
The oom killer, both global and memcg, will defer if it finds an eligible
process that is in the process of exiting and it is not being ptraced.
The idea is to allow it to exit without using memory reserves before
needlessly killing another process.
This normally works fine except in the memcg case with a large number of
threads attached to the oom memcg. In this case, the memcg oom killer
only gets called for the process that grabs the hierarchy's oom lock; all
others end up blocked on the memcg's oom waitqueue. Thus, if the process
that grabs the hierarchy's oom lock is never the first PF_EXITING process
in the memcg's task iteration, the oom killer is constantly deferred
without anything making progress.
The fix is to give PF_EXITING processes access to memory reserves so that
we've marked them as oom killed without any iteration. This allows
__mem_cgroup_try_charge() to succeed so that the process may exit. This
makes the memcg oom killer exemption for TIF_MEMDIE tasks, now
immediately granted for processes with pending SIGKILLs and those in the
exit path, to be equivalent to what is done for the global oom killer.
Signed-off-by: David Rientjes
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1686,11 +1686,11 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup
*memcg, gfp_t gfp_mask,
struct task_struct *chosen = NULL;
/*
-* If current has a pending SIGKILL, then automatically select it. The
-* goal is to allow it to allocate so that it may quickly exit and free
-* its memory.
+* If current has a pending SIGKILL or is exiting, then automatically
+* select it. The goal is to allow it to allocate so that it may
+* quickly exit and free its memory.
*/
- if (fatal_signal_pending(current)) {
+ if (fatal_signal_pending(current) || current->flags & PF_EXITING) {
set_thread_flag(TIF_MEMDIE);
return;
}
--
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] xen: Don't call arch_trigger_all_cpu_backtrace in dom0(pvm)
On 2013-03-29 21:46, Konrad Rzeszutek Wilk wrote: On Fri, Mar 29, 2013 at 03:22:38PM +0800, Zhenzhong Duan wrote: nmi isn't supported in dom0, fallback to general all cpu backtrace code. Without fix, on xapic system, sysrq+l, no backtrace is showed. On x2apic enabled system, got NULL pointer dereference as below. Why would the x2APIC or xAPIC make a difference here? The Linux dom0 is not fiddling with the APIC - that is the hypervisor job. In x2apic enabled system, dom0 kernel set apic pointer to apic_x2apic_cluster or apic_x2apic_phys. When sending nmi, apic->send_IPI_all copy cpumask which isn't initialized. For xapic system, apic->send_IPI_all=xen_send_IPI_all apic, this func does nothing for nmi, so no backtrace. Can you explain to me why x2apic_send_IPI_mask is even set? Wouldn't the Xen version of send_IPI be present? (See xen_smp_ops) It's overwrited by x2apic initialization. The problem is even without overwrite, like xapic system, xen_send_IPI_all doesn't work for nmi vector. zduan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/4] workqueue: Add system wide system_freezable_unbound_wq
On 1 April 2013 10:50, Amit Kucheria wrote: > On Sun, Mar 31, 2013 at 8:01 PM, Viresh Kumar wrote: >> This patch adds system wide system_freezable_unbound_wq which will be used by >> code that currently uses system_freezable_wq and can be moved to unbound >> workqueues. > > _Why_ do i need this change? Block layer uses system_freezable_wq for some work and to migrate them to a UNBOUND wq it was required. Sorry if it is yet not clear. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/4] workqueue: Add system wide system_freezable_unbound_wq
On Sun, Mar 31, 2013 at 8:01 PM, Viresh Kumar wrote:
> This patch adds system wide system_freezable_unbound_wq which will be used by
> code that currently uses system_freezable_wq and can be moved to unbound
> workqueues.
_Why_ do i need this change?
> Signed-off-by: Viresh Kumar
> ---
> include/linux/workqueue.h | 4
> kernel/workqueue.c| 7 ++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 835d12b..ab7597b 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -325,11 +325,15 @@ enum {
> *
> * system_freezable_wq is equivalent to system_wq except that it's
> * freezable.
> + *
> + * system_freezable_unbound_wq is equivalent to system_unbound_wq except that
> + * it's freezable.
> */
> extern struct workqueue_struct *system_wq;
> extern struct workqueue_struct *system_long_wq;
> extern struct workqueue_struct *system_unbound_wq;
> extern struct workqueue_struct *system_freezable_wq;
> +extern struct workqueue_struct *system_freezable_unbound_wq;
>
> static inline struct workqueue_struct * __deprecated __system_nrt_wq(void)
> {
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index df2f6c4..771a5cc 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -281,6 +281,8 @@ struct workqueue_struct *system_unbound_wq __read_mostly;
> EXPORT_SYMBOL_GPL(system_unbound_wq);
> struct workqueue_struct *system_freezable_wq __read_mostly;
> EXPORT_SYMBOL_GPL(system_freezable_wq);
> +struct workqueue_struct *system_freezable_unbound_wq __read_mostly;
> +EXPORT_SYMBOL_GPL(system_freezable_unbound_wq);
>
> static int worker_thread(void *__worker);
> static void copy_workqueue_attrs(struct workqueue_attrs *to,
> @@ -4467,8 +4469,11 @@ static int __init init_workqueues(void)
> WQ_UNBOUND_MAX_ACTIVE);
> system_freezable_wq = alloc_workqueue("events_freezable",
> WQ_FREEZABLE, 0);
> + system_freezable_unbound_wq =
> alloc_workqueue("events_unbound_freezable",
> + WQ_FREEZABLE | WQ_UNBOUND, 0);
> BUG_ON(!system_wq || !system_highpri_wq || !system_long_wq ||
> - !system_unbound_wq || !system_freezable_wq);
> + !system_unbound_wq || !system_freezable_wq ||
> + !system_freezable_unbound_wq);
> return 0;
> }
> early_initcall(init_workqueues);
> --
> 1.7.12.rc2.18.g61b472e
>
>
> ___
> linaro-kernel mailing list
> linaro-ker...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] sched: factor out code to should_we_balance()
On Fri, Mar 29, 2013 at 12:58:26PM +0100, Peter Zijlstra wrote:
> On Thu, 2013-03-28 at 16:58 +0900, Joonsoo Kim wrote:
> > +static int should_we_balance(struct lb_env *env)
> > +{
> > + struct sched_group *sg = env->sd->groups;
> > + int cpu, balance_cpu = -1;
> > +
> > + /*
> > +* In the newly idle case, we will allow all the cpu's
> > +* to do the newly idle load balance.
> > +*/
> > + if (env->idle == CPU_NEWLY_IDLE)
> > + return 1;
> > +
> > + /* Try to find first idle cpu */
> > + for_each_cpu_and(cpu, sched_group_cpus(sg), env->cpus)
> > + if (cpumask_test_cpu(cpu, sched_group_mask(sg)) &&
> > + idle_cpu(cpu)) {
> > + balance_cpu = cpu;
> > + break;
> > + }
>
> /me hands you a bucket of curlies too.. use them I'll send you another
> bucket when this one gets empty!
Thanks!
> (We always put in curlies on multi lines statements -- as opposed to
> multi statement blocks where they're required)
Okay. I will do that when respin.
Thanks.
>
> > +
> > + if (balance_cpu == -1)
> > + balance_cpu = group_balance_cpu(sg);
> > +
> > + /*
> > +* First idle cpu or the first cpu(busiest) in this sched
> > group
> > +* is eligible for doing load balancing at this and above
> > domains.
> > +*/
> > + if (balance_cpu != env->dst_cpu)
> > + return 0;
> > +
> > + return 1;
> > +}
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] soft-offline: use migrate_pages() instead of migrate_huge_page()
Michal Hocko writes: > On Tue 26-03-13 16:59:40, Aneesh Kumar K.V wrote: >> Naoya Horiguchi writes: > [...] >> > diff --git v3.9-rc3.orig/mm/memory-failure.c v3.9-rc3/mm/memory-failure.c >> > index df0694c..4e01082 100644 >> > --- v3.9-rc3.orig/mm/memory-failure.c >> > +++ v3.9-rc3/mm/memory-failure.c >> > @@ -1467,6 +1467,7 @@ static int soft_offline_huge_page(struct page *page, >> > int flags) >> >int ret; >> >unsigned long pfn = page_to_pfn(page); >> >struct page *hpage = compound_head(page); >> > + LIST_HEAD(pagelist); >> > >> >/* >> > * This double-check of PageHWPoison is to avoid the race with >> > @@ -1482,12 +1483,20 @@ static int soft_offline_huge_page(struct page >> > *page, int flags) >> >unlock_page(hpage); >> > >> >/* Keep page count to indicate a given hugepage is isolated. */ >> > - ret = migrate_huge_page(hpage, new_page, MPOL_MF_MOVE_ALL, >> > - MIGRATE_SYNC); >> > - put_page(hpage); >> > + list_move(>lru, ); >> >> we use hpage->lru to add the hpage to h->hugepage_activelist. This will >> break a hugetlb cgroup removal isn't it ? > > This particular part will not break removal because > hugetlb_cgroup_css_offline loops until hugetlb_cgroup_have_usage is 0. > But we still need to hold hugetlb_lock around that right ? -aneesh -- 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] sched: factor out code to should_we_balance()
Hello, Peter. On Fri, Mar 29, 2013 at 12:45:14PM +0100, Peter Zijlstra wrote: > On Thu, 2013-03-28 at 16:58 +0900, Joonsoo Kim wrote: > > There is not enough reason to place this checking at > > update_sg_lb_stats(), > > except saving one iteration for sched_group_cpus. But with this > > change, > > we can save two memset cost and can expect better compiler > > optimization, > > so clean-up may be more beneficial to us. > > It would be good if you'd described what you actually did, there's a > lot of code movement and now I have to figure out wth you did and why. Okay. I will do that when respin. Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] sched: limit sched_slice if it is more than sysctl_sched_latency
Hello Preeti. On Fri, Mar 29, 2013 at 05:05:37PM +0530, Preeti U Murthy wrote: > Hi Joonsoo > > On 03/28/2013 01:28 PM, Joonsoo Kim wrote: > > sched_slice() compute ideal runtime slice. If there are many tasks > > in cfs_rq, period for this cfs_rq is extended to guarantee that each task > > has time slice at least, sched_min_granularity. And then each task get > > a portion of this period for it. If there is a task which have much larger > > load weight than others, a portion of period can exceed far more than > > sysctl_sched_latency. > > Correct. But that does not matter, the length of the scheduling latency > period is determined by the return value of ___sched_period(), not the > value of sysctl_sched_latency. You would not extend the period,if you > wanted all tasks to have a slice within the sysctl_sched_latency, right? > > So since the value of the length of the scheduling latency period, is > dynamic depending on the number of the processes running, the > sysctl_sched_latency which is the default latency period length is not > mesed with, but is only used as a base to determine the actual > scheduling period. > > > > > For exampple, you can simply imagine that one task with nice -20 and > > 9 tasks with nice 0 on one cfs_rq. In this case, load weight sum for > > this cfs_rq is 88761 + 9 * 1024, 97977. So a portion of slice for the > > task with nice -20 is sysctl_sched_min_granularity * 10 * (88761 / 97977), > > that is, approximately, sysctl_sched_min_granularity * 9. This aspect > > can be much larger if there is more tasks with nice 0. > > Yeah so the __sched_period says that within 40ms, all tasks need to be > scheduled ateast once, and the highest priority task gets nearly 36ms of > it, while the rest is distributed among the others. > > > > > So we should limit this possible weird situation. > > > > Signed-off-by: Joonsoo Kim > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index e232421..6ceffbc 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -645,6 +645,9 @@ static u64 sched_slice(struct cfs_rq *cfs_rq, struct > > sched_entity *se) > > } > > slice = calc_delta_mine(slice, se->load.weight, load); > > > > + if (unlikely(slice > sysctl_sched_latency)) > > + slice = sysctl_sched_latency; > > Then in this case the highest priority thread would get > 20ms(sysctl_sched_latency), and the rest would get > sysctl_sched_min_granularity * 10 * (1024/97977) which would be 0.4ms. > Then all tasks would get scheduled ateast once within 20ms + (0.4*9) ms > = 23.7ms, while your scheduling latency period was extended to 40ms,just > so that each of these tasks don't have their sched_slices shrunk due to > large number of tasks. I don't know I understand your question correctly. I will do my best to answer your comment. :) With this patch, I just limit maximum slice at one time. Scheduling is controlled through the vruntime. So, in this case, the task with nice -20 will be scheduled twice. 20 + (0.4 * 9) + 20 = 43.9 ms And after 43.9 ms, this process is repeated. So I can tell you that scheduling period is preserved as before. If we give a long period to a task at one go, it can cause a latency problem. So IMHO, limiting this is meaningful. Thanks. > > > + > > return slice; > > } > > > > Regards > Preeti U Murthy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memcg: avoid accessing memcg after releasing reference
(2013/04/01 11:39), Li Zefan wrote: > This might cause use-after-free bug. > > Signed-off-by: Li Zefan Thank you. Acked-by: KAMEZAWA Hiroyuki -- 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 0/21] sched: power aware scheduling
On 03/30/2013 10:34 PM, Alex Shi wrote: [snip] > > Some performance testing results: > - > > Tested benchmarks: kbuild, specjbb2005, oltp, tbench, aim9, > hackbench, fileio-cfq of sysbench, dbench, aiostress, multhreads > loopback netperf. on my core2, nhm, wsm, snb, platforms. Hi, Alex I've tested the patch on my 12 cpu X86 box with 3.9.0-rc2, here is the results of pgbench (a rough test with little float): baseperformance powersaving | db_size | clients | tps | | tps | | tps | +-+-+---+ +---+ +---+ | 22 MB | 1 | 10662 | | 10497 | | 10124 | | 22 MB | 2 | 21483 | | 21398 | | 17400 | | 22 MB | 4 | 42046 | | 41974 | | 33473 | | 22 MB | 8 | 55807 | | 53504 | | 45320 | | 22 MB | 12 | 50768 | | 49657 | | 47469 | | 22 MB | 16 | 49880 | | 49189 | | 48328 | | 22 MB | 24 | 45904 | | 45870 | | 44756 | | 22 MB | 32 | 43420 | | 44183 | | 43552 | | 7484 MB | 1 | 7965 | | 9045 | | 8221 | | 7484 MB | 2 | 19354 | | 19593 | | 14525 | | 7484 MB | 4 | 37552 | | 37459 | | 28348 | | 7484 MB | 8 | 48655 | | 46974 | | 42360 | | 7484 MB | 12 | 45778 | | 45410 | | 43800 | | 7484 MB | 16 | 45659 | | 44303 | | 42265 | | 7484 MB | 24 | 42192 | | 40571 | | 39197 | | 7484 MB | 32 | 36385 | | 36535 | | 36066 | | 15 GB | 1 | 7677 | | 7362 | | 8075 | | 15 GB | 2 | 19227 | | 19033 | | 14796 | | 15 GB | 4 | 37335 | | 37186 | | 28923 | | 15 GB | 8 | 48130 | | 50232 | | 42281 | | 15 GB | 12 | 45393 | | 44266 | | 42763 | | 15 GB | 16 | 45110 | | 43973 | | 42647 | | 15 GB | 24 | 41415 | | 39389 | | 38844 | | 15 GB | 32 | 35988 | | 36175 | | 35247 | For the performance one, a bit win here and a bit lost there, well, since little float is there, I think at least, no regression. But the powersaving one suffered some regression in low-end, is that the sacrifice we supposed to do for power saving? Regards, Michael Wang > > results: > A, no clear performance change found on 'performance' policy. > B, specjbb2005 drop 5~7% on both of policy whenever with openjdk or >jrockit on powersaving polocy > C, hackbench drops 40% with powersaving policy on snb 4 sockets platforms. > Others has no clear change. > > === > Changelog: > V6 change: > a, remove 'balance' policy. > b, consider RT task effect in balancing > c, use avg_idle as burst wakeup indicator > d, balance on task utilization in fork/exec/wakeup. > e, no power balancing on SMT domain. > > V5 change: > a, change sched_policy to sched_balance_policy > b, split fork/exec/wake power balancing into 3 patches and refresh > commit logs > c, others minors clean up > > V4 change: > a, fix few bugs and clean up code according to Morten Rasmussen, Mike > Galbraith and Namhyung Kim. Thanks! > b, take Morten Rasmussen's suggestion to use different criteria for > different policy in transitory task packing. > c, shorter latency in power aware scheduling. > > V3 change: > a, engaged nr_running and utilisation in periodic power balancing. > b, try packing small exec/wake tasks on running cpu not idle cpu. > > V2 change: > a, add lazy power scheduling to deal with kbuild like benchmark. > > > -- Thanks Alex > [patch v6 01/21] Revert "sched: Introduce temporary FAIR_GROUP_SCHED > [patch v6 02/21] sched: set initial value of runnable avg for new > [patch v6 03/21] sched: only count runnable avg on cfs_rq's > [patch v6 04/21] sched: add sched balance policies in kernel > [patch v6 05/21] sched: add sysfs interface for sched_balance_policy > [patch v6 06/21] sched: log the cpu utilization at rq > [patch v6 07/21] sched: add new sg/sd_lb_stats fields for incoming > [patch v6 08/21] sched: move sg/sd_lb_stats struct ahead > [patch v6 09/21] sched: scale_rt_power rename and meaning change > [patch v6 10/21] sched: get rq potential maximum utilization > [patch v6 11/21] sched: detect wakeup burst with rq->avg_idle > [patch v6 12/21] sched: add power aware scheduling in fork/exec/wake > [patch v6 13/21] sched: using avg_idle to detect bursty wakeup > [patch v6 14/21] sched: packing transitory tasks in wakeup power > [patch v6 15/21] sched: add power/performance balance allow flag > [patch v6 16/21] sched: pull all tasks from source group > [patch v6 17/21] sched: no balance for prefer_sibling in power > [patch v6 18/21] sched: add new members of sd_lb_stats > [patch v6 19/21] sched: power aware load balance > [patch v6 20/21] sched: lazy power balance > [patch v6 21/21] sched: don't do power balance on share cpu power > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to
Re: [PATCH] memcg: take reference before releasing rcu_read_lock
(2013/03/29 19:28), Li Zefan wrote: > The memcg is not referenced, so it can be destroyed at anytime right > after we exit rcu read section, so it's not safe to access it. > > To fix this, we call css_tryget() to get a reference while we're still > in rcu read section. > > This also removes a bogus comment above __memcg_create_cache_enqueue(). > > Signed-off-by: Li Zefan Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] ia64: cpufreq: move cpufreq driver to drivers/cpufreq
On 30 March 2013 15:21, Viresh Kumar wrote: > Fixup: > > commit 509bc3c30aff65045918f69f750d8845f004cc0a > Author: Viresh Kumar > Date: Sat Mar 30 15:20:41 2013 +0530 > > fixup! ia64: cpufreq: move cpufreq driver to drivers/cpufreq > --- > arch/ia64/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index dd59848..152b5f2 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -593,6 +593,7 @@ source "drivers/acpi/Kconfig" > if PM > menu "CPU Frequency scaling" > source "drivers/cpufreq/Kconfig" > +endmenu > endif > > endmenu Hi Tony/Fenghua, Any comments on this patch? -- 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] pwm: mxs: Remove unused *dev from struct spear_pwm_chip
On 1 April 2013 08:19, Axel Lin wrote:
Apart from fixing subject you need to write something in logs too..
> Signed-off-by: Axel Lin
> ---
> drivers/pwm/pwm-spear.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
> index 3223b57..9563599 100644
> --- a/drivers/pwm/pwm-spear.c
> +++ b/drivers/pwm/pwm-spear.c
> @@ -49,13 +49,11 @@
> * @mmio_base: base address of pwm chip
> * @clk: pointer to clk structure of pwm chip
> * @chip: linux pwm chip representation
> - * @dev: pointer to device structure of pwm chip
> */
> struct spear_pwm_chip {
> void __iomem *mmio_base;
> struct clk *clk;
> struct pwm_chip chip;
> - struct device *dev;
> };
>
> static inline struct spear_pwm_chip *to_spear_pwm_chip(struct pwm_chip *chip)
> @@ -200,7 +198,6 @@ static int spear_pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pc->clk))
> return PTR_ERR(pc->clk);
>
> - pc->dev = >dev;
> platform_set_drvdata(pdev, pc);
>
> pc->chip.dev = >dev;
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] THP: Use explicit memory barrier
Hey Kame, On Mon, Apr 01, 2013 at 10:01:49AM +0900, Kamezawa Hiroyuki wrote: > (2013/04/01 8:45), Minchan Kim wrote: > > __do_huge_pmd_anonymous_page depends on page_add_new_anon_rmap's > > spinlock for making sure that clear_huge_page write become visible > > after set set_pmd_at() write. > > > > But lru_cache_add_lru uses pagevec so it could miss spinlock > > easily so above rule was broken so user may see inconsistent data. > > This patch fixes it with using explict barrier rather than depending > > on lru spinlock. > > > > Hmm...how about do_anonymous_page() ? there are no comments/locks/barriers. > Users can see non-zero value after page fault in theory ? Maybe, but as you know well, we didn't see any report about that until now so I'm not sure. Ccing people in this thread could have clear answer rather than me. In THP, I just found inconsistency between Andrea's comment and code. That's why I sent a patch. If your concern turns out truth, Ya, you might find ancient bug. :) Thanks. > > Thanks, > -Kame > > -- > 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 -- Kind regards, Minchan Kim -- 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] misc/vmw_vmci: VMWARE_VMCI depends on NET
Fix: ERROR: "memcpy_toiovec" [drivers/misc/vmw_vmci/vmw_vmci.ko] undefined! ERROR: "memcpy_fromiovec" [drivers/misc/vmw_vmci/vmw_vmci.ko] undefined! Both functions are defined in the core networking code. Signed-off-by: Guenter Roeck --- drivers/misc/vmw_vmci/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig index 39c2eca..ea98f7e 100644 --- a/drivers/misc/vmw_vmci/Kconfig +++ b/drivers/misc/vmw_vmci/Kconfig @@ -4,7 +4,7 @@ config VMWARE_VMCI tristate "VMware VMCI Driver" - depends on X86 && PCI + depends on X86 && PCI && NET help This is VMware's Virtual Machine Communication Interface. It enables high-speed communication between host and guest in a virtual -- 1.7.9.7 -- 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 8/9] spark: cpufreq: move cpufreq driver to drivers/cpufreq
On 31 March 2013 22:10, David Miller wrote: >> On 26 March 2013 09:55, Viresh Kumar wrote: >>> From: Viresh Kumar >>> Date: Mon, 25 Mar 2013 11:20:23 +0530 >>> Subject: [PATCH] sparc: cpufreq: move cpufreq driver to drivers/cpufreq > Subject line still has the "spark" typo. Your mail was scary, really... HOW can i do it?? And then i saw how you got it wrong. I haven't sent a new mail, so mails subject remains the same... I copied V2 in the same mail.. Check above, subject looks fine :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pinctrl: tegra: add suspend-resume support
Hi Stephen,
My response inline.
Regards
Bibek
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Thursday, March 28, 2013 11:19 PM
To: Bibek Basu
Cc: Linus Walleij; linux-kernel@vger.kernel.org; Pritesh Raithatha
Subject: Re: [PATCH] pinctrl: tegra: add suspend-resume support
On 03/28/2013 11:11 AM, Bibek Basu wrote:
> From: Pritesh Raithatha
>
> This patch adds suspend and resume callbacks to the pinctrl-tegra driver.
>
> Based on work by:
> Pritesh Raithatha
Those two lines are somewhat implied by the fact the commit's git author field
is Pritesh, and his s-o-b line is included below.
[BB]: Will get rid of the above lines.
> Signed-off-by: Pritesh Raithatha
> Signed-off-by: Bibek Basu
> diff --git a/drivers/pinctrl/pinctrl-tegra.c
> b/drivers/pinctrl/pinctrl-tegra.c
> +static struct tegra_pmx *pmx;
Isn't there any way to pass data into the suspend/resume functions so that this
global isn't needed?
Why can't we just use the device suspend/resume functions rather than global
(syscore) suspend/resume functions? Presumably this is to ensure that all other
drivers suspend first, then the pinctrl driver does, and the reverse for
resume. Can't we rely on deferred probe to ensure that instead?
To make that work, we might need every affected driver to define a dummy pinmux
state in DT that references the pinctrl driver, to make sure they all get
probed after the pinctrl driver.
[BB]: Before I add dummy pinmux state in DT of affected driver, I would like to
know the following:
1> The usage of syscore api needs global data. So, are you suggesting that
syscore APIs are not appropriate to be used or syscore implementation is not
proper?
2> Adding dummy DT states may give scope for BUGS. Reason being there must
be someone checking that every time some new driver refrences pinmux driver,
should put a dummy entry in device tree. Isnt it more time costing then
having "static struct tegra_pmx *pmx;"?
> +#ifdef CONFIG_PM_SLEEP
Perhaps we can remove the ifdefs, and always compile this code. The compiler
should remove any unused functions from the final linked image.
[BB]: Will do
> int tegra_pinctrl_probe(struct platform_device *pdev,
> const struct tegra_pinctrl_soc_data *soc_data) -{
> - struct tegra_pmx *pmx;
> + {
The indentation of the { is wrong there.
[BB]: Will fix
> +#ifdef CONFIG_PM_SLEEP
I think you can use if (IS_ENABLED(CONFIG_PM_SLEEP)) here instead of an ifdef.
This will allow the code to be compiled in all cases (to allow better compile
coverage), but it will be optimized out if CONFIG_PM_SLEEP isn't enabled. Can
you please make that change, and verify that it works?
[BB]: Will do.
The same comment applies to the other ifdefs below.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] pwm: spear: Remove unused *dev from struct spear_pwm_chip
Signed-off-by: Axel Lin
Acked-by: Shiraz Hashim
---
v2: fix the prefix in subject line
drivers/pwm/pwm-spear.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
index 3223b57..9563599 100644
--- a/drivers/pwm/pwm-spear.c
+++ b/drivers/pwm/pwm-spear.c
@@ -49,13 +49,11 @@
* @mmio_base: base address of pwm chip
* @clk: pointer to clk structure of pwm chip
* @chip: linux pwm chip representation
- * @dev: pointer to device structure of pwm chip
*/
struct spear_pwm_chip {
void __iomem *mmio_base;
struct clk *clk;
struct pwm_chip chip;
- struct device *dev;
};
static inline struct spear_pwm_chip *to_spear_pwm_chip(struct pwm_chip *chip)
@@ -200,7 +198,6 @@ static int spear_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pc->clk))
return PTR_ERR(pc->clk);
- pc->dev = >dev;
platform_set_drvdata(pdev, pc);
pc->chip.dev = >dev;
--
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 4/5] sched: don't consider upper se in sched_slice()
Hello, Preeti. On Fri, Mar 29, 2013 at 12:42:53PM +0530, Preeti U Murthy wrote: > Hi Joonsoo, > > On 03/28/2013 01:28 PM, Joonsoo Kim wrote: > > Following-up upper se in sched_slice() should not be done, > > because sched_slice() is used for checking that resched is needed > > whithin *this* cfs_rq and there is one problem related to this > > in current implementation. > > > > The problem is that if we follow-up upper se in sched_slice(), it is > > possible that we get a ideal slice which is lower than > > sysctl_sched_min_granularity. > > > > For example, we assume that we have 4 tg which is attached to root tg > > with same share and each one have 20 runnable tasks on cpu0, respectivly. > > In this case, __sched_period() return sysctl_sched_min_granularity * 20 > > and then go into loop. At first iteration, we compute a portion of slice > > for this task on this cfs_rq, so get a slice, sysctl_sched_min_granularity. > > Afterward, we enter second iteration and get a slice which is a quarter of > > sysctl_sched_min_granularity, because there is 4 tgs with same share > > in that cfs_rq. > > > > Ensuring slice larger than min_granularity is important for performance > > and there is no lower bound about this, except timer tick, we should > > fix it not to consider upper se when calculating sched_slice. > > > > I am assuming the sysctl_sched_latency = 20ms and > sysctl_sched_min_granularity = 4ms. > In that case: > > With your patch, the sum of the sched_slice(runnable_task) on each_tg is > 40ms = sched_min_granularity * 10, while the parent tg has a > sched_slice of sysctl_sched_latency / 4 = (20 / 4) = 5ms. > > Ideally the children's cpu share must add upto the parent's share. > I don't think so. We should schedule out the parent tg if 5ms is over. As we do so, we can fairly distribute time slice to every tg within short term. If we add the children's cpu share upto the parent's, the parent tg may have large time slice, so it cannot be preempted easily. There may be a latency problem if there are many tgs. Thanks. > > Thank you > > Regards > Preeti U Murthy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] KVM: MMU: make kvm_mmu_zap_all preemptable
kvm_mmu_zap_all is a slow path, break the mmu-lock if needed to
avoid potential soft lockup
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 633e30c..1ebca53 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4181,12 +4181,21 @@ void kvm_mmu_zap_all(struct kvm *kvm)
struct kvm_mmu_page *sp, *node;
LIST_HEAD(invalid_list);
+ might_sleep();
+
spin_lock(>mmu_lock);
restart:
- list_for_each_entry_safe(sp, node, >arch.active_mmu_pages, link)
+ list_for_each_entry_safe(sp, node, >arch.active_mmu_pages, link) {
if (kvm_mmu_prepare_zap_page(kvm, sp, _list))
goto restart;
+ if (need_resched() || spin_needbreak(>mmu_lock)) {
+ kvm_mmu_commit_zap_page(kvm, _list);
+ cond_resched_lock(>mmu_lock);
+ goto restart;
+ }
+ }
+
kvm_mmu_commit_zap_page(kvm, _list);
spin_unlock(>mmu_lock);
}
--
1.7.7.6
--
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] KVM: MMU: drop unnecessary kvm_reload_remote_mmus
It is the responsibility of kvm_mmu_zap_all that keeps the
consistent of mmu and tlbs. And it is also unnecessary after
zap all mmio sptes since no mmio spte exists on root shadow
page and it can not be cached into tlb
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/x86.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2aaba81..9ce99ed 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6988,16 +6988,13 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
* If memory slot is created, or moved, we need to clear all
* mmio sptes.
*/
- if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE)) {
+ if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE))
kvm_mmu_zap_mmio_sptes(kvm);
- kvm_reload_remote_mmus(kvm);
- }
}
void kvm_arch_flush_shadow_all(struct kvm *kvm)
{
kvm_mmu_zap_all(kvm);
- kvm_reload_remote_mmus(kvm);
}
void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
--
1.7.7.6
--
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] KVM: x86: avoid potential soft lockup and unneeded mmu reload
This patch makes kvm_mmu_zap_all be preemptable since it is a slow path, break the mmu-lock if needed to avoid potential soft lockup. Also it drops unnecessary kvm_reload_remote_mmus This is the preparing work about kvm_mmu_zap_all, the fast approach is being developed Xiao Guangrong (2): KVM: MMU: make kvm_mmu_zap_all preemptable KVM: MMU: drop unnecessary kvm_reload_remote_mmus arch/x86/kvm/mmu.c | 11 ++- arch/x86/kvm/x86.c |5 + 2 files changed, 11 insertions(+), 5 deletions(-) -- 1.7.7.6 -- 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] checkpatch: do not exit in main process subroutine
On Sat, 2013-03-30 at 18:30 +0800, zhangwei(Jovi) wrote:
> On 2013/3/28 11:43, zhangwei(Jovi) wrote:
> > Currently checkpatch program exit when process empty file,
> > This will cause issue when @ARGV include many files ready to check.
[]
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > @@ -3634,19 +3634,19 @@ sub process {
> > # If we have no input at all, then there is nothing to report on
> > # so just keep quiet.
> > if ($#rawlines == -1) {
> > - exit(0);
> > + return $clean;
> > }
I think instead this should be something like adding
if (!is_patch && $#rawlines == -1) {
return $clean;
}
though maybe expecting checkpatch to avoid empty files
when fed a directory list is unrealistic.
--
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] pwm: mxs: Remove unused *dev from struct spear_pwm_chip
Hi Axel,
Perhaps you meant pwm: spear: (instead of pwm: mxs) in the subject
line.
On Mon, Apr 01, 2013 at 10:49:25AM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/pwm/pwm-spear.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
> index 3223b57..9563599 100644
> --- a/drivers/pwm/pwm-spear.c
> +++ b/drivers/pwm/pwm-spear.c
> @@ -49,13 +49,11 @@
> * @mmio_base: base address of pwm chip
> * @clk: pointer to clk structure of pwm chip
> * @chip: linux pwm chip representation
> - * @dev: pointer to device structure of pwm chip
> */
> struct spear_pwm_chip {
> void __iomem *mmio_base;
> struct clk *clk;
> struct pwm_chip chip;
> - struct device *dev;
> };
>
> static inline struct spear_pwm_chip *to_spear_pwm_chip(struct pwm_chip *chip)
> @@ -200,7 +198,6 @@ static int spear_pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pc->clk))
> return PTR_ERR(pc->clk);
>
> - pc->dev = >dev;
> platform_set_drvdata(pdev, pc);
>
> pc->chip.dev = >dev;
> --
> 1.7.10.4
otherwise,
Acked-by: Shiraz Hashim
--
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] drivers/usb/serial: looping issue: avoid the return value overriden by looping
inside the 'for' looping: the return value 'rv' may override if not have a check in time. next checking, outside the 'for' looping: can not find failure which generated during the 'for' looping so need let outside know about the failure. Signed-off-by: Chen Gang --- drivers/usb/serial/mos7840.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c index a0d5ea5..13aae1e 100644 --- a/drivers/usb/serial/mos7840.c +++ b/drivers/usb/serial/mos7840.c @@ -651,7 +651,9 @@ static void mos7840_interrupt_callback(struct urb *urb) wreg = MODEM_STATUS_REGISTER; break; } - rv = mos7840_get_reg(mos7840_port, wval, wreg, ); + if (mos7840_get_reg(mos7840_port, wval, + wreg, ) < 0) + rv = -1; } } } -- 1.7.7.6 -- 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] pwm: spear: Fix enable pwm output
On Sat, Mar 30, 2013 at 05:55:41PM +0800, Viresh Kumar wrote: > On 30 March 2013 11:07, Axel Lin wrote: > > The logic to check return value of clk_enable() is reversed, thus > > when clk_enable() passes PWMCR_PWM_ENABLE bit is not set. Fix it. > > > > Signed-off-by: Axel Lin > > --- > > drivers/pwm/pwm-spear.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > I am so sorry. clk_prepare also has the same issue :( > Please fix that too and i will ack it ASAP. > > @Shiraz: Any idea how they went through? I don't remember how :(, surely a mistake which escaped tests also. -- regards Shiraz -- 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] NMI: fix NMI period is not correct when cpu frequency changes issue.
Watchdog use performance monitor of cpu clock cycle to generate NMI to detect
hard lockup.
But when cpu's frequency changes, the event period will also change.
It's not as expected as the configuration.
For example, set the NMI event handler period is 10 seconds when the cpu is
2.0GHz.
If the cpu changes to 800MHz, the period will be 10*(2000/800)=25 seconds.
So it may make hard lockup detect not work if the watchdog timeout is not long
enough.
Now, set a notifier to listen to the cpu frequency change.
And dynamic re-config the NMI event to make the event period correct.
Signed-off-by: Pan Zhenjie
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d795df..717fdac 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -564,7 +564,8 @@ extern void perf_pmu_migrate_context(struct pmu *pmu,
int src_cpu, int dst_cpu);
extern u64 perf_event_read_value(struct perf_event *event,
u64 *enabled, u64 *running);
-
+extern void perf_dynamic_adjust_period(struct perf_event *event,
+ u64 sample_period);
struct perf_sample_data {
u64 type;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 59412d0..96596d1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -2428,6 +2429,42 @@ static void perf_adjust_period(struct perf_event *event,
u64 nsec, u64 count, bo
}
}
+static int perf_percpu_dynamic_adjust_period(void *info)
+{
+ struct perf_event *event = (struct perf_event *)info;
+ s64 left;
+ u64 old_period = event->hw.sample_period;
+ u64 new_period = event->attr.sample_period;
+ u64 shift = 0;
+
+ /* precision is enough */
+ while (old_period > 0xF && new_period > 0xF) {
+ old_period >>= 1;
+ new_period >>= 1;
+ shift++;
+ }
+
+ event->pmu->stop(event, PERF_EF_UPDATE);
+
+ left = local64_read(>hw.period_left);
+ left = (s64)div64_u64(left * (event->attr.sample_period >> shift),
+ (event->hw.sample_period >> shift));
+ local64_set(>hw.period_left, left);
+
+ event->hw.sample_period = event->attr.sample_period;
+
+ event->pmu->start(event, PERF_EF_RELOAD);
+
+ return 0;
+}
+
+void perf_dynamic_adjust_period(struct perf_event *event, u64 sample_period)
+{
+ event->attr.sample_period = sample_period;
+ cpu_function_call(event->cpu, perf_percpu_dynamic_adjust_period, event);
+}
+EXPORT_SYMBOL_GPL(perf_dynamic_adjust_period);
+
/*
* combine freq adjustment with unthrottling to avoid two passes over the
* events. At the same time, make sure, having freq events does not change
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 4a94467..34a953a 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
int watchdog_enabled = 1;
int __read_mostly watchdog_thresh = 10;
@@ -470,6 +471,31 @@ static void watchdog_nmi_disable(unsigned int cpu)
}
return;
}
+
+static int watchdog_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct perf_event *event;
+ struct cpufreq_freqs *freq = data;
+
+ if (val == CPUFREQ_POSTCHANGE) {
+ event = per_cpu(watchdog_ev, freq->cpu);
+ perf_dynamic_adjust_period(event,
+ (u64)freq->new * 1000 * watchdog_thresh);
+ }
+
+ return 0;
+}
+
+static int __init watchdog_cpufreq(void)
+{
+ static struct notifier_block watchdog_nb;
+ watchdog_nb.notifier_call = watchdog_cpufreq_transition;
+ cpufreq_register_notifier(_nb, CPUFREQ_TRANSITION_NOTIFIER);
+
+ return 0;
+}
+late_initcall(watchdog_cpufreq);
#else
static int watchdog_nmi_enable(unsigned int cpu) { return 0; }
static void watchdog_nmi_disable(unsigned int cpu) { return; }
--
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/
Linux 3.9-rc5
Another week, another -rc. I'm like the US postal office - "Neither snow nor rain nor heat nor gloom of night" will keep me from doing weekly -rc releases. A little holiday like Easter? Bah, humbug. It might delay the release email a few hours because a man gotta stuff himself with odd seasonal desserts (and the Finnish Easter desserts are odder than most), but it won't stop the inevitable progress towards a final 3.9 release. So there it is. A shiny new release candidate, just waiting for testing. Nothing really peculiar stands out. Exynos DRM updates, IBM RamSan driver updates are a bit larger, l2tp update... The rest is pretty much small patches spread out all over. Mostly drivers (block, net, media, tty, usb), networking, and some filesystem updates (btrfs, nfs). Some arch updates (x86, arc). Things seem to be calming down a bit, and everything seems largely on track for a 3.9 release in a few weeks. Linus --- Aaro Koskinen (1): omapfb: fix broken build on OMAP1 Al Viro (4): Don't bother with redoing rw_verify_area() from default_file_splice_from() Nest rename_lock inside vfsmount_lock vt: synchronize_rcu() under spinlock is not nice... vfs/splice: Fix missed checks in new __kernel_write() helper Alex Elder (1): rbd: don't zero-fill non-image object requests Alex Williamson (2): igb: Fix null pointer dereference igb: SR-IOV init reordering Alexandru Gheorghiu (1): drm/exynos: Replaced kzalloc & memcpy with kmemdup Alice Ferrazzi (1): Block: blk-flush: Fixed indent code style Amitkumar Karwar (1): mwifiex: fix race when queuing commands Andrey Vagin (1): net: fix *_DIAG_MAX constants Andrzej Hajda (1): [media] m5mols: Fix bug in stream on handler Andy King (1): VMCI: Fix process-to-process DRGAMs. Andy Shevchenko (1): dw_dmac: adjust slave_id accordingly to request line base Archit Taneja (1): omapdss: features: fix supported outputs for OMAP4 Arnd Bergmann (3): iommu: OMAP: build only on OMAP2+ [media] ir: IR_RX51 only works on OMAP2 dmaengine: dw_dma: fix endianess for DT xlate function Arun Kumar K (2): [media] s5p-mfc: Fix frame skip bug [media] s5p-mfc: Fix encoder control 15 issue Axel Lin (1): pinctrl: abx500: Fix checking if pin use AlternateFunction register Ben Hutchings (2): efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE ARM64: early_printk: Fix check for CONFIG_ARM64_64K_PAGES Benjamin Tissoires (1): HID: multitouch: fix touchpad buttons Bing Zhao (2): mwifiex: skip pending commands after function shutdown mwifiex: cancel cmd timer and free curr_cmd in shutdown process CQ Tang (1): x86-64: Fix the failure case in copy_user_handle_tail() Chanwoo Choi (3): extcon: max8997: Check the pointer of platform data to protect null pointer error extcon: max77693: Fix bug of wrong pointer when platform data is not used extcon: max77693: Initialize register of MUIC device to bring up it without platform data Chen Gang (2): xen/xen-blkback: preq.dev is used without initialized powerpc: make additional room in exception vector area Chen Gong (1): ACPI / APEI: fix error status check condition for CPER Chris Mason (1): Btrfs: fix race between mmap writes and compression Cong Wang (1): 8021q: fix a potential use-after-free Dan Carpenter (1): IB/ipath: Silence a static checker warning Daniel Borkmann (1): flow_keys: include thoff into flow_keys for later usage Daniel Vetter (2): Revert "drm/i915: set TRANSCODER_EDP even earlier" Revert "drm/i915: write backlight harder" David Vrabel (2): xen/blkback: correctly respond to unknown, non-native requests xen/events: avoid race with raising an event in unmask_evtchn() Dirk Brandewie (2): cpufreq / intel_pstate: Add function to check that all MSRs are valid cpufreq / intel_pstate: Fix calculation of current frequency Eric Dumazet (2): tcp: preserve ACK clocking in TSO net: remove a WARN_ON() in net_enable_timestamp() Eric W. Biederman (8): scm: Require CAP_SYS_ADMIN over the current pidns to spoof pids. pid: Handle the exit of a multi-threaded init. yama: Better permission check for ptraceme userns: Don't allow creation if the user is chrooted vfs: Add a mount flag to lock read only bind mounts vfs: Carefully propogate mounts across user namespaces ipc: Restrict mounting the mqueue filesystem userns: Restrict when proc and sysfs can be mounted Fabio Estevam (2): net: fec: Define indexes as 'unsigned int' fec: Fix the build as module Fabio Valentini (1): ACPI / PM: fix suspend and resume on Sony Vaio VGN-FW21M Felix Fietkau (2): ath9k_hw: revert chainmask to user configuration after calibration ath9k: limit tx path hang check to normal
[GIT] Networking
1) sadb_msg prepared for IPSEC userspace forgets to initialize the satype field, fix from Nicolas Dichtel. 2) Fix mac80211 synchronization during station removal, from Johannes Berg. 3) Fix IPSEC sequence number notifications when they wrap, from Steffen Klassert. 4) Fix cfg80211 wdev tracing crashes when add_virtual_intf() returns an error pointer, from Johannes Berg. 5) In mac80211, don't call into the channel context code with the interface list mutex held. From Johannes Berg. 6) In mac80211, if we don't actually associate, do not restart the STA timer, otherwise we can crash. From Ben Greear. 7) Missing dma_mapping_error() check in e1000, ixgb, and e1000e. From Christoph Paasch. 8) Fix sja1000 driver defines to not conflict with SH port, from Marc Kleine-Budde. 9) Don't call il4965_rs_use_green with a NULL station, from Colin Ian King. 10) Suspend/Resume in the FEC driver fail because the buffer descriptors are not initialized at all the moments in which they should. Fix from Frank Li. 11) cpsw and davinci_emac drivers both use the wrong interface to restart a stopped TX queue. Use netif_wake_queue not netif_start_queue, the latter is for initialization/bringup not active management of the queue. From Mugunthan V N. 12) Fix regression in rate calculations done by psched_ratecfg_precompute(), missing u64 type promotion. From Sergey Popovich. 13) Fix length overflow in tg3 VPD parsing, from Kees Cook. 14) AOE driver fails to allocate enough headroom, resulting in crashes. Fix from Eric Dumazet. 15) RX overflow happens too quickly in sky2 driver because pause packet thresholds are not programmed correctly. From Mirko Lindner. 16) Bonding driver manages arp_interval and miimon settings incorrectly, disabling one unintentionally disables both. Fix from Nikolay Aleksandrov. 17) smsc75xx drivers don't program the RX mac properly for jumbo frames. Fix from Steve Glendinning. 18) Fix off-by-one in Codel packet scheduler. From Vijay Subramanian. 19) Fix packet corruption in atl1c by disabling MSI support, from Hannes Frederic Sowa. 20) netdev_rx_handler_unregister() needs a synchronize_net() to fix crashes in bonding driver unload stress tests. From Eric Dumazet. 21) rxlen field of ks8851 RX packet descriptors not interpreted correctly (it is 12 bits not 16 bits, so needs to be masked after shifting the 32-bit value down 16 bits). Fix from Max Nekludov. 22) Fix missed RX/TX enable in sh_eth driver due to mishandling of link change indications. From Sergei Shtylyov. 23) Fix crashes during spurious ECI interrupts in sh_eth driver, also from Sergei Shtylyov. 24) dm9000 driver initialization is done wrong for revision B devices with DSP PHY, from Joseph CHANG. Please pull, thanks a lot! The following changes since commit a8c45289f215e137825bf9630d0abb41c1dc41ff: Merge tag 'iommu-fixes-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu (2013-03-27 09:25:11 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 6741f40d198c6a5feb23653a1efd4ca47f93d83d: DM9000B: driver initialization upgrade (2013-03-31 19:43:23 -0400) Avinash Patil (1): mwifiex: reset skb->data after processing PCIe sleep confirm cmd respose Ben Greear (1): mac80211: Don't restart sta-timer if not associated. Christoph Paasch (3): e1000: ethtool: Add missing dma_mapping_error-call in e1000_setup_desc_rings ixgb: Add missing dma_mapping_error-call in ixgb_alloc_rx_buffers e1000e: Add missing dma_mapping_error-call in e1000_alloc_jumbo_rx_buffers Colin Ian King (1): iwlegacy: 4965-rs: avoid null pointer dereference error Dan Williams (1): libertas: drop maintainership David S. Miller (4): Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec Merge branch 'master' of git://git.kernel.org/.../jkirsher/net Merge branch 'fixes-for-3.9' of git://gitorious.org/linux-can/linux-can Merge branch 'wireless' Dmitry Kravkov (1): line up comment for ndo_bridge_getlink Emmanuel Grumbach (3): iwlwifi: fix length check in multi-TB HCMD iwlwifi: set rfkill in internal state of the transport iwlwifi: dvm: don't send HCMD in restart flow Eric Dumazet (2): aoe: reserve enough headroom on skbs net: add a synchronize_net() in netdev_rx_handler_unregister() Frank Li (1): enet: fec: fix fail resume from suspend state Hannes Frederic Sowa (2): ipv6: don't accept node local multicast traffic from the wire atl1e: drop pci-msi support because of packet corruption Iestyn C. Elfick (1): b43: A fix for DMA transmission sequence errors Johannes Berg (6): mac80211: always synchronize_net() during station
[PATCH 3/3] pstore/ram: Restore ecc information block
From: Arve Hjønnevåg
This was lost when proc/last_kmsg moved to pstore/console-ramoops.
Signed-off-by: Arve Hjønnevåg
Signed-off-by: John Stultz
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c | 12 ++--
fs/pstore/ram_core.c | 3 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index a5ee252..32cbd7c 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -136,6 +136,7 @@ static ssize_t ramoops_pstore_read(u64 *id, enum
pstore_type_id *type,
char **buf, struct pstore_info *psi)
{
ssize_t size;
+ ssize_t ecc_notice_size;
struct ramoops_context *cxt = psi->data;
struct persistent_ram_zone *prz;
@@ -156,11 +157,18 @@ static ssize_t ramoops_pstore_read(u64 *id, enum
pstore_type_id *type,
time->tv_nsec = 0;
size = persistent_ram_old_size(prz);
- *buf = kmemdup(persistent_ram_old(prz), size, GFP_KERNEL);
+
+ /* ECC correction notice */
+ ecc_notice_size = persistent_ram_ecc_string(prz, NULL, 0);
+
+ *buf = kmalloc(size + ecc_notice_size + 1, GFP_KERNEL);
if (*buf == NULL)
return -ENOMEM;
- return size;
+ memcpy(*buf, persistent_ram_old(prz), size);
+ persistent_ram_ecc_string(prz, *buf + size, ecc_notice_size + 1);
+
+ return size + ecc_notice_size;
}
static size_t ramoops_write_kmsg_hdr(struct persistent_ram_zone *prz)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index c6f641c..5933732 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -235,6 +235,9 @@ ssize_t persistent_ram_ecc_string(struct
persistent_ram_zone *prz,
{
ssize_t ret;
+ if (!prz->ecc_info.ecc_size)
+ return 0;
+
if (prz->corrected_bytes || prz->bad_blocks)
ret = snprintf(str, len, ""
"\n%d Corrected bytes, %d unrecoverable blocks\n",
--
1.8.1.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 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)
On Sun, Mar 31, 2013 at 3:56 PM, Rafael J. Wysocki wrote: > > So, I have two patches (on top of the Linus' tree) that will follow shortly: Should I take these directly as patches, or expect them to show up in a pull soon (ie do you have or expect to have other things pending)? 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 2/3] pstore/ram: Allow specifying ecc parameters in platform data
From: Arve Hjønnevåg
Allow specifying ecc parameters in platform data
Signed-off-by: Arve Hjønnevåg
[jstultz: Tweaked commit subject & add commit message]
Signed-off-by: John Stultz
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c| 15 ++-
fs/pstore/ram_core.c | 64 --
include/linux/pstore_ram.h | 14 +++---
3 files changed, 52 insertions(+), 41 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 38babb3..a5ee252 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -83,7 +83,7 @@ struct ramoops_context {
size_t console_size;
size_t ftrace_size;
int dump_oops;
- int ecc_size;
+ struct persistent_ram_ecc_info ecc_info;
unsigned int max_dump_cnt;
unsigned int dump_write_cnt;
unsigned int dump_read_cnt;
@@ -322,7 +322,8 @@ static int ramoops_init_przs(struct device *dev, struct
ramoops_context *cxt,
for (i = 0; i < cxt->max_dump_cnt; i++) {
size_t sz = cxt->record_size;
- cxt->przs[i] = persistent_ram_new(*paddr, sz, 0, cxt->ecc_size);
+ cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
+ >ecc_info);
if (IS_ERR(cxt->przs[i])) {
err = PTR_ERR(cxt->przs[i]);
dev_err(dev, "failed to request mem region
(0x%zx@0x%llx): %d\n",
@@ -352,7 +353,7 @@ static int ramoops_init_prz(struct device *dev, struct
ramoops_context *cxt,
return -ENOMEM;
}
- *prz = persistent_ram_new(*paddr, sz, sig, cxt->ecc_size);
+ *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info);
if (IS_ERR(*prz)) {
int err = PTR_ERR(*prz);
@@ -406,7 +407,7 @@ static int ramoops_probe(struct platform_device *pdev)
cxt->console_size = pdata->console_size;
cxt->ftrace_size = pdata->ftrace_size;
cxt->dump_oops = pdata->dump_oops;
- cxt->ecc_size = pdata->ecc_size;
+ cxt->ecc_info = pdata->ecc_info;
paddr = cxt->phys_addr;
@@ -464,9 +465,9 @@ static int ramoops_probe(struct platform_device *pdev)
record_size = pdata->record_size;
dump_oops = pdata->dump_oops;
- pr_info("attached 0x%lx@0x%llx, ecc: %d\n",
+ pr_info("attached 0x%lx@0x%llx, ecc: %d/%d\n",
cxt->size, (unsigned long long)cxt->phys_addr,
- cxt->ecc_size);
+ cxt->ecc_info.ecc_size, cxt->ecc_info.block_size);
return 0;
@@ -538,7 +539,7 @@ static void ramoops_register_dummy(void)
* For backwards compatibility ramoops.ecc=1 means 16 bytes ECC
* (using 1 byte for ECC isn't much of use anyway).
*/
- dummy_data->ecc_size = ramoops_ecc == 1 ? 16 : ramoops_ecc;
+ dummy_data->ecc_info.ecc_size = ramoops_ecc == 1 ? 16 : ramoops_ecc;
dummy = platform_device_register_data(NULL, "ramoops", -1,
dummy_data, sizeof(struct ramoops_platform_data));
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index e5afa22..c6f641c 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -82,12 +82,12 @@ static void notrace persistent_ram_encode_rs8(struct
persistent_ram_zone *prz,
uint8_t *data, size_t len, uint8_t *ecc)
{
int i;
- uint16_t par[prz->ecc_size];
+ uint16_t par[prz->ecc_info.ecc_size];
/* Initialize the parity buffer */
memset(par, 0, sizeof(par));
encode_rs8(prz->rs_decoder, data, len, par, 0);
- for (i = 0; i < prz->ecc_size; i++)
+ for (i = 0; i < prz->ecc_info.ecc_size; i++)
ecc[i] = par[i];
}
@@ -95,9 +95,9 @@ static int persistent_ram_decode_rs8(struct
persistent_ram_zone *prz,
void *data, size_t len, uint8_t *ecc)
{
int i;
- uint16_t par[prz->ecc_size];
+ uint16_t par[prz->ecc_info.ecc_size];
- for (i = 0; i < prz->ecc_size; i++)
+ for (i = 0; i < prz->ecc_info.ecc_size; i++)
par[i] = ecc[i];
return decode_rs8(prz->rs_decoder, data, par, len,
NULL, 0, NULL, 0, NULL);
@@ -110,15 +110,15 @@ static void notrace persistent_ram_update_ecc(struct
persistent_ram_zone *prz,
uint8_t *buffer_end = buffer->data + prz->buffer_size;
uint8_t *block;
uint8_t *par;
- int ecc_block_size = prz->ecc_block_size;
- int ecc_size = prz->ecc_size;
- int size = prz->ecc_block_size;
+ int ecc_block_size = prz->ecc_info.block_size;
+ int ecc_size = prz->ecc_info.ecc_size;
+ int size = ecc_block_size;
- if (!prz->ecc_size)
+ if (!ecc_size)
return;
block = buffer->data + (start & ~(ecc_block_size - 1));
- par = prz->par_buffer + (start / ecc_block_size) * prz->ecc_size;
+ par = prz->par_buffer + (start / ecc_block_size) * ecc_size;
[PATCH 1/3] pstore/ram: Include ecc_size when calculating ecc_block
From: Arve Hjønnevåg
Wastes less memory and allows using more memory for ecc than data.
Signed-off-by: Arve Hjønnevåg
[jstultz: Tweaked commit subject]
Signed-off-by: John Stultz
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 0306303..e5afa22 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -187,7 +187,8 @@ static int persistent_ram_init_ecc(struct
persistent_ram_zone *prz,
prz->ecc_block_size = 128;
prz->ecc_size = ecc_size;
- ecc_blocks = DIV_ROUND_UP(prz->buffer_size, prz->ecc_block_size);
+ ecc_blocks = DIV_ROUND_UP(prz->buffer_size - prz->ecc_size,
+ prz->ecc_block_size + prz->ecc_size);
ecc_total = (ecc_blocks + 1) * prz->ecc_size;
if (ecc_total >= prz->buffer_size) {
pr_err("%s: invalid ecc_size %u (total %zu, buffer size %zu)\n",
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Sync Android pstore updates
Hi all, Here are a few updates from the Android dev tree. Thanks to Arve Hjønnevåg for the code, and John Stultz for actually preparing commits for submission. Unless there are objections, I'll push these updates to linux-pstore.git. Thanks! Anton -- 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: [Suggestion] drivers/usb/serial: looping issue: return value may override by looping
On 2013年04月01日 11:05, Greg KH wrote: > No. Please send real patches if you think something is wrong, after > determining something is incorrect. To waste people's time like this, > checking to see if you have misunderstood something, does not scale at > all, please be more considerate. ok, thanks. next, I should try to send patches at any condition. :-) -- Chen Gang Asianux Corporation -- 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: [Suggestion] drivers/usb/serial: looping issue: return value may override by looping
On Mon, Apr 01, 2013 at 10:52:57AM +0800, Chen Gang wrote: > Hello Maintainers: > > in drivers/usb/serial/mos7840.c: > > in 'for' looping (line 632..657) > the return value 'rv' may override if not have a check in time (line 654) > > next checking can not find failure which generated during looping (line 658) > > please help check, thanks. No. Please send real patches if you think something is wrong, after determining something is incorrect. To waste people's time like this, checking to see if you have misunderstood something, does not scale at all, please be more considerate. 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 1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()
On Mon, Apr 01, 2013 at 12:57:21AM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb > "usb: Add driver/usb/core/(port.c,hub.h) files", from > usb_port_device_release(), because (1) it is completely unnecessary > (the flags have been removed already by the PM core during the > unregistration of the device object) and (2) it triggers a NULL > pointer dereference in sysfs_find_dirent() (dev->kobj->sd is NULL at > this point). > > Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] r8169: fix auto speed down issue
It would cause no link after suspending or shutdowning when the
nic changes the speed to 10M and connects to a link partner which
forces the speed to 100M.
Check the link partner ability to determine which speed to set.
Signed-off-by: Hayes Wang
---
drivers/net/ethernet/realtek/r8169.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 28fb50a..bdc03a9 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3818,6 +3818,30 @@ static void rtl_init_mdio_ops(struct rtl8169_private *tp)
}
}
+static void rtl_speed_down(struct rtl8169_private *tp)
+{
+ u32 adv;
+ int lpa;
+
+ rtl_writephy(tp, 0x1f, 0x);
+ lpa = rtl_readphy(tp, MII_LPA);
+
+ if (lpa & (LPA_10HALF | LPA_10FULL))
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
+ else if (lpa & (LPA_100HALF | LPA_100FULL))
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
+ else
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
+ (tp->mii.supports_gmii ?
+ ADVERTISED_1000baseT_Half |
+ ADVERTISED_1000baseT_Full : 0);
+
+ rtl8169_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
+ adv);
+}
+
static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -3848,9 +3872,7 @@ static bool rtl_wol_pll_power_down(struct rtl8169_private
*tp)
if (!(__rtl8169_get_wol(tp) & WAKE_ANY))
return false;
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, MII_BMCR, 0x);
-
+ rtl_speed_down(tp);
rtl_wol_suspend_quirk(tp);
return true;
--
1.8.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/
[Suggestion] drivers/usb/serial: looping issue: return value may override by looping
Hello Maintainers:
in drivers/usb/serial/mos7840.c:
in 'for' looping (line 632..657)
the return value 'rv' may override if not have a check in time (line 654)
next checking can not find failure which generated during looping (line 658)
please help check, thanks.
gchen.
579 static void mos7840_interrupt_callback(struct urb *urb)
580 {
581 int result;
582 int length;
583 struct moschip_port *mos7840_port;
584 struct usb_serial *serial;
585 __u16 Data;
586 unsigned char *data;
587 __u8 sp[5], st;
588 int i, rv = 0;
589 __u16 wval, wreg = 0;
590 int status = urb->status;
591
592 switch (status) {
593 case 0:
594 /* success */
595 break;
596 case -ECONNRESET:
597 case -ENOENT:
598 case -ESHUTDOWN:
599 /* this urb is terminated, clean up */
600 dev_dbg(>dev->dev, "%s - urb shutting down with
status: %d\n",
601 __func__, status);
602 return;
603 default:
604 dev_dbg(>dev->dev, "%s - nonzero urb status received:
%d\n",
605 __func__, status);
606 goto exit;
607 }
608
609 length = urb->actual_length;
610 data = urb->transfer_buffer;
611
612 serial = urb->context;
613
614 /* Moschip get 5 bytes
615 * Byte 1 IIR Port 1 (port.number is 0)
616 * Byte 2 IIR Port 2 (port.number is 1)
617 * Byte 3 IIR Port 3 (port.number is 2)
618 * Byte 4 IIR Port 4 (port.number is 3)
619 * Byte 5 FIFO status for both */
620
621 if (length && length > 5) {
622 dev_dbg(>dev->dev, "%s", "Wrong data !!!\n");
623 return;
624 }
625
626 sp[0] = (__u8) data[0];
627 sp[1] = (__u8) data[1];
628 sp[2] = (__u8) data[2];
629 sp[3] = (__u8) data[3];
630 st = (__u8) data[4];
631
632 for (i = 0; i < serial->num_ports; i++) {
633 mos7840_port = mos7840_get_port_private(serial->port[i]);
634 wval =
635 (((__u16) serial->port[i]->number -
636 (__u16) (serial->minor)) + 1) << 8;
637 if (mos7840_port->open) {
638 if (sp[i] & 0x01) {
639 dev_dbg(>dev->dev, "SP%d No Interrupt
!!!\n", i);
640 } else {
641 switch (sp[i] & 0x0f) {
642 case SERIAL_IIR_RLS:
643 dev_dbg(>dev->dev, "Serial
Port %d: Receiver status error or \n", i);
644 dev_dbg(>dev->dev, "address
bit detected in 9-bit mode\n");
645 mos7840_port->MsrLsr = 1;
646 wreg = LINE_STATUS_REGISTER;
647 break;
648 case SERIAL_IIR_MS:
649 dev_dbg(>dev->dev, "Serial
Port %d: Modem status change\n", i);
650 mos7840_port->MsrLsr = 0;
651 wreg = MODEM_STATUS_REGISTER;
652 break;
653 }
654 rv = mos7840_get_reg(mos7840_port, wval,
wreg, );
655 }
656 }
657 }
658 if (!(rv < 0))
659 /* the completion handler for the control urb will
resubmit */
660 return;
661 exit:
662 result = usb_submit_urb(urb, GFP_ATOMIC);
663 if (result) {
664 dev_err(>dev->dev,
665 "%s - Error %d submitting interrupt urb\n",
666 __func__, result);
667 }
668 }
--
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] pwm: mxs: Remove unused *dev from struct spear_pwm_chip
Signed-off-by: Axel Lin
---
drivers/pwm/pwm-spear.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
index 3223b57..9563599 100644
--- a/drivers/pwm/pwm-spear.c
+++ b/drivers/pwm/pwm-spear.c
@@ -49,13 +49,11 @@
* @mmio_base: base address of pwm chip
* @clk: pointer to clk structure of pwm chip
* @chip: linux pwm chip representation
- * @dev: pointer to device structure of pwm chip
*/
struct spear_pwm_chip {
void __iomem *mmio_base;
struct clk *clk;
struct pwm_chip chip;
- struct device *dev;
};
static inline struct spear_pwm_chip *to_spear_pwm_chip(struct pwm_chip *chip)
@@ -200,7 +198,6 @@ static int spear_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pc->clk))
return PTR_ERR(pc->clk);
- pc->dev = >dev;
platform_set_drvdata(pdev, pc);
pc->chip.dev = >dev;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] pwm: mxs: Remove unused *dev from struct mxs_pwm_chip
Signed-off-by: Axel Lin
---
drivers/pwm/pwm-mxs.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index a53d309..23d5180 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -38,7 +38,6 @@
struct mxs_pwm_chip {
struct pwm_chip chip;
- struct device *dev;
struct clk *clk;
void __iomem *base;
};
@@ -166,7 +165,6 @@ static int mxs_pwm_probe(struct platform_device *pdev)
return ret;
}
- mxs->dev = >dev;
platform_set_drvdata(pdev, mxs);
stmp_reset_block(mxs->base);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] memcg: avoid accessing memcg after releasing reference
This might cause use-after-free bug. Signed-off-by: Li Zefan --- found when reading the code. --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 8ec501c..6391046 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3186,12 +3186,12 @@ void memcg_release_cache(struct kmem_cache *s) root = s->memcg_params->root_cache; root->memcg_params->memcg_caches[id] = NULL; - mem_cgroup_put(memcg); mutex_lock(>slab_caches_mutex); list_del(>memcg_params->list); mutex_unlock(>slab_caches_mutex); + mem_cgroup_put(memcg); out: kfree(s->memcg_params); } -- 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] ipc,sem: prevent releasing RCU read lock twice in semctl_main
We will release RCU read lock twice if the sem id passed from userspace is
not within the legal range in semctl_main.
Reviewed-by: Rik van Riel
Reviewed-by: Davidlohr Bueso
Signed-off-by: Sasha Levin
---
ipc/sem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 6e109ef..ac36671 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1333,8 +1333,10 @@ static int semctl_main(struct ipc_namespace *ns, int
semid, int semnum,
/* GETVAL, GETPID, GETNCTN, GETZCNT: fall-through */
}
err = -EINVAL;
- if(semnum < 0 || semnum >= nsems)
- goto out_unlock;
+ if(semnum < 0 || semnum >= nsems) {
+ rcu_read_unlock();
+ goto out_wakeup;
+ }
sem_lock(sma, NULL, -1);
curr = >sem_base[semnum];
--
1.8.1.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] pinctrl: pinctrl-mxs: document the missing pull-ups
On Sat, Mar 30, 2013 at 12:51:12AM +0100, Alexandre Belloni wrote:
> Some pins on the i.mx23 and i.mx28 are missing pull-ups, document that
> oddity because it was difficult to know the expected behaviour.
>
> Signed-off-by: Alexandre Belloni
Applied, thanks.
> ---
>
> I don't think it is necessary to list the pins with the missing pull ups in
> that file but we may want to explicitly direct to the datasheet as even with
> the same chip, it can depend on the package (BGA or QFP for example).
>
> Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
> index f7e8e8f..3077370 100644
> --- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
> @@ -70,6 +70,10 @@ Optional subnode-properties:
> 0: Disable the internal pull-up
> 1: Enable the internal pull-up
>
> +Note that when enabling the pull-up, the internal pad keeper gets disabled.
> +Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
> +will only disable the internal pad keeper.
> +
> Examples:
>
> pinctrl@80018000 {
> --
> 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] ARM: timer: Shutdown clock event device when stopping local timer
2013/4/1 Daniel Lezcano :
> On 03/29/2013 10:24 AM, ning.n.ji...@gmail.com wrote:
>> From: Ning Jiang
>>
>> Currently there are two problems when we try to stop local timer.
>> First, it calls set_mode function directly so mode state is not
>> updated for the clock event device. Second, it makes the device
>> unused instead of shutdown.
>>
>> A subtle error will happen because of it. When a cpu is plugged out
>> it will stop the local timer. It will call tick_nohz_idle_enter()
>> in idle thread afterwards. It will cancel the sched timer and try
>> to reprogram the next event. This is wrong since the local timer
>> is supposed to be stopped.
>>
>> The right way to stop the local timer is to shutdown it by calling
>> clockevents_set_mode(). Thus when we try to reprogram the clock
>> event device, it will return directly without doing anything since
>> the clock mode is CLOCK_EVT_MODE_SHUTDOWN.
>>
>> Signed-off-by: Ning Jiang
>> ---
>
>
> Don't you see a kernel BUG with this patch ?
>
> In the clockevents code, there is:
>
> /**
> * clockevents_notify - notification about relevant events
> */
> void clockevents_notify(unsigned long reason, void *arg)
> {
> ...
> case CLOCK_EVT_NOTIFY_CPU_DEAD:
> ...
> cpu = *((int *)arg);
> list_for_each_entry_safe(dev, tmp, _devices,
> list) {
>if (cpumask_test_cpu(cpu, dev->cpumask) &&
> cpumask_weight(dev->cpumask) == 1 &&
> !tick_is_broadcast_device(dev)) {
> BUG_ON(dev->mode !=
> CLOCK_EVT_MODE_UNUSED);
>
> ^^
>
> list_del(>list);
> }
> }
> break;
> ...
> }
>
> This is called triggered from hrtimer_cpu_notify with the CPU_DEAD event.
>
The clockevents_do_notify() in clockevents_notify() will call
tick_notify() which will call tick_shutdown() in turn. tick_shutdown()
will set clock event device mode to UNUSED. So no panic afterwards.
void clockevents_notify(unsigned long reason, void *arg)
{
...
clockevents_do_notify(reason, arg);
switch (reason) {
case CLOCK_EVT_NOTIFY_CPU_DEAD:
...
list_for_each_entry_safe(dev, tmp, _devices, list) {
if (cpumask_test_cpu(cpu, dev->cpumask) &&
cpumask_weight(dev->cpumask) == 1 &&
!tick_is_broadcast_device(dev)) {
BUG_ON(dev->mode != CLOCK_EVT_MODE_UNUSED);
list_del(>list);
}
}
}
raw_spin_unlock_irqrestore(_lock, flags);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: timer: Shutdown clock event device when stopping local timer
2013/4/1 Daniel Lezcano :
> On 03/29/2013 10:24 AM, ning.n.ji...@gmail.com wrote:
>> From: Ning Jiang
>>
>> Currently there are two problems when we try to stop local timer.
>> First, it calls set_mode function directly so mode state is not
>> updated for the clock event device. Second, it makes the device
>> unused instead of shutdown.
>>
>> A subtle error will happen because of it. When a cpu is plugged out
>> it will stop the local timer. It will call tick_nohz_idle_enter()
>> in idle thread afterwards. It will cancel the sched timer and try
>> to reprogram the next event. This is wrong since the local timer
>> is supposed to be stopped.
>>
>> The right way to stop the local timer is to shutdown it by calling
>> clockevents_set_mode(). Thus when we try to reprogram the clock
>> event device, it will return directly without doing anything since
>> the clock mode is CLOCK_EVT_MODE_SHUTDOWN.
>>
>> Signed-off-by: Ning Jiang
>> ---
>> arch/arm/kernel/smp_twd.c|2 +-
>> arch/arm/mach-exynos/mct.c |2 +-
>> arch/arm/mach-msm/timer.c|2 +-
>> drivers/clocksource/arm_arch_timer.c |2 +-
>> drivers/clocksource/time-armada-370-xp.c |2 +-
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
>> index 3f25650..c1d4ab4 100644
>> --- a/arch/arm/kernel/smp_twd.c
>> +++ b/arch/arm/kernel/smp_twd.c
>> @@ -92,7 +92,7 @@ static int twd_timer_ack(void)
>>
>> static void twd_timer_stop(struct clock_event_device *clk)
>> {
>> - twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
>> + clockevents_set_mode(clk, CLOCK_EVT_MODE_SHUTDOWN);
>> disable_percpu_irq(clk->irq);
>
> Wouldn't be clockevents_shutdown more adequate here ? The next event
> will be also set.
You're right. clockevents_shutdown seems more appropriate here. I'll
submit a revised patch for it.
> --
> Facebook |
> Twitter |
>
Re: [PATCH] ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices()
On 04/01/2013 08:25 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The ACPI handle of struct i2c_adapter's dev member should not be
> set, because this causes that struct i2c_adapter to be associated
> with the ACPI device node corresponding to its parent as the
> second "physical_device", which is incorrect (this happens during
> the registration of struct i2c_adapter). Consequently,
> acpi_i2c_register_devices() should use the ACPI handle of the
> parent of the struct i2c_adapter it is called for rather than the
> struct i2c_adapter's ACPI handle (which should be NULL).
>
> Make that happen and modify the i2c-designware-platdrv driver,
> which currently is the only driver for ACPI-enumerated I2C
> controller chips, not to set the ACPI handle for the
> struct i2c_adapter it creates.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
Thanks,
Aaron
> ---
> drivers/acpi/acpi_i2c.c |2 +-
> drivers/i2c/busses/i2c-designware-platdrv.c |1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpi_i2c.c
> ===
> --- linux-pm.orig/drivers/acpi/acpi_i2c.c
> +++ linux-pm/drivers/acpi/acpi_i2c.c
> @@ -90,7 +90,7 @@ void acpi_i2c_register_devices(struct i2
> acpi_handle handle;
> acpi_status status;
>
> - handle = ACPI_HANDLE(>dev);
> + handle = ACPI_HANDLE(adapter->dev.parent);
> if (!handle)
> return;
>
> Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
> ===
> --- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -182,7 +182,6 @@ static int dw_i2c_probe(struct platform_
> adap->algo = _dw_algo;
> adap->dev.parent = >dev;
> adap->dev.of_node = pdev->dev.of_node;
> - ACPI_HANDLE_SET(>dev, ACPI_HANDLE(>dev));
>
> r = i2c_add_numbered_adapter(adap);
> if (r) {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] THP: Use explicit memory barrier
(2013/04/01 8:45), Minchan Kim wrote: > __do_huge_pmd_anonymous_page depends on page_add_new_anon_rmap's > spinlock for making sure that clear_huge_page write become visible > after set set_pmd_at() write. > > But lru_cache_add_lru uses pagevec so it could miss spinlock > easily so above rule was broken so user may see inconsistent data. > This patch fixes it with using explict barrier rather than depending > on lru spinlock. > Hmm...how about do_anonymous_page() ? there are no comments/locks/barriers. Users can see non-zero value after page fault in theory ? Thanks, -Kame -- 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] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras
Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera.
Signed-off-by: John McMaster
---
drivers/media/usb/gspca/Kconfig | 10 +
drivers/media/usb/gspca/Makefile |2 +
drivers/media/usb/gspca/touptek.c | 857 +
3 files changed, 869 insertions(+)
create mode 100644 drivers/media/usb/gspca/touptek.c
diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig
index 6345f93..113f181 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -376,6 +376,16 @@ config USB_GSPCA_TOPRO
To compile this driver as a module, choose M here: the
module will be called gspca_topro.
+config USB_GSPCA_TOUPTEK
+ tristate "Touptek USB Camera Driver"
+ depends on VIDEO_V4L2 && USB_GSPCA
+ help
+ Say Y here if you want support for cameras based on the ToupTek UCMOS
+ / AmScope MU series camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_touptek.
+
config USB_GSPCA_TV8532
tristate "TV8532 USB Camera Driver"
depends on VIDEO_V4L2 && USB_GSPCA
diff --git a/drivers/media/usb/gspca/Makefile b/drivers/media/usb/gspca/Makefile
index c901da0..5f18e7f 100644
--- a/drivers/media/usb/gspca/Makefile
+++ b/drivers/media/usb/gspca/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_USB_GSPCA_STK014) += gspca_stk014.o
obj-$(CONFIG_USB_GSPCA_STV0680) += gspca_stv0680.o
obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o
obj-$(CONFIG_USB_GSPCA_TOPRO)+= gspca_topro.o
+obj-$(CONFIG_USB_GSPCA_TOUPTEK) += gspca_touptek.o
obj-$(CONFIG_USB_GSPCA_TV8532) += gspca_tv8532.o
obj-$(CONFIG_USB_GSPCA_VC032X) += gspca_vc032x.o
obj-$(CONFIG_USB_GSPCA_VICAM)+= gspca_vicam.o
@@ -82,6 +83,7 @@ gspca_stv0680-objs := stv0680.o
gspca_sunplus-objs := sunplus.o
gspca_t613-objs := t613.o
gspca_topro-objs:= topro.o
+gspca_touptek-objs := touptek.o
gspca_tv8532-objs := tv8532.o
gspca_vc032x-objs := vc032x.o
gspca_vicam-objs:= vicam.o
diff --git a/drivers/media/usb/gspca/touptek.c
b/drivers/media/usb/gspca/touptek.c
new file mode 100644
index 000..9ce31f0
--- /dev/null
+++ b/drivers/media/usb/gspca/touptek.c
@@ -0,0 +1,857 @@
+/*
+ * ToupTek UCMOS / AmScope MU series camera driver
+ * TODO: contrast with ScopeTek / AmScope MDC cameras
+ *
+ * Copyright (C) 2012 John McMaster
+ *
+ * Special thanks to Bushing for helping with the decrypt algorithm and
+ * Sean O'Sullivan / the Rensselaer Center for Open Source
+ * Software (RCOS) for helping me learn kernel development
+ *
+ * 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
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "gspca.h"
+
+#define MODULE_NAME "touptek"
+
+MODULE_AUTHOR("John McMaster");
+MODULE_DESCRIPTION("ToupTek UCMOS / Amscope MU microscope camera driver");
+MODULE_LICENSE("GPL");
+
+/*
+Register value is linear with exposure time
+Exposure (sec), E (reg)
+0.000400, 0x0002
+0.001000, 0x0005
+0.005000, 0x0019
+0.02, 0x0064
+0.08, 0x0190
+0.40, 0x07D0
+1.00, 0x1388
+2.00, 0x2710
+*/
+#define INDEX_EXPOSURE 0x3012
+#define INDEX_WIDTH0x034C
+#define INDEX_HEIGHT 0x034E
+
+/*
+Gain does not vary with resolution (checked 640x480 vs 1600x1200)
+Range 0x1000 (nothing) to 0x11FF (highest)
+However, there appear to be gaps
+
+Suspect three gain stages
+0x1000: master channel enable bit
+0x007F: low gain bits
+0x0080: medium gain bit
+0x0100: high gain bit
+
+gain = enable * (1 + regH) * (1 + regM) * z * regL
+
+zR = 0.0069605943152454778
+ about 3/431 = 0.0069605568445475635
+zB = 0.0095695970695970703
+ about 6/627 = 0.0095693779904306216
+zG = 0.010889328063241107
+ about 6/551 = 0.010889292196007259
+about 10 bits for constant + 7 bits for value => at least 17 bit intermediate
+with 32 bit ints should be fine for overflow etc
+Essentially gains are in range 0-0x001FF
+
+However, V4L expects a main gain channel + R and B balance
+To keep things simple for now saturate the values of balance is too high/low
+This isn't really ideal but easy way to fit the Linux model
+
+Raw data:
+Gain, GTOP, B, R, GBOT
+1.00, 0x105C, 0x1068, 0x10C8, 0x105C
+1.20, 0x106E, 0x107E, 0x10D6, 0x106E
+1.40, 0x10C0, 0x10CA, 0x10E5, 0x10C0
+1.60, 0x10C9,
[PATCH] ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices()
From: Rafael J. Wysocki
The ACPI handle of struct i2c_adapter's dev member should not be
set, because this causes that struct i2c_adapter to be associated
with the ACPI device node corresponding to its parent as the
second "physical_device", which is incorrect (this happens during
the registration of struct i2c_adapter). Consequently,
acpi_i2c_register_devices() should use the ACPI handle of the
parent of the struct i2c_adapter it is called for rather than the
struct i2c_adapter's ACPI handle (which should be NULL).
Make that happen and modify the i2c-designware-platdrv driver,
which currently is the only driver for ACPI-enumerated I2C
controller chips, not to set the ACPI handle for the
struct i2c_adapter it creates.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/acpi_i2c.c |2 +-
drivers/i2c/busses/i2c-designware-platdrv.c |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
Index: linux-pm/drivers/acpi/acpi_i2c.c
===
--- linux-pm.orig/drivers/acpi/acpi_i2c.c
+++ linux-pm/drivers/acpi/acpi_i2c.c
@@ -90,7 +90,7 @@ void acpi_i2c_register_devices(struct i2
acpi_handle handle;
acpi_status status;
- handle = ACPI_HANDLE(>dev);
+ handle = ACPI_HANDLE(adapter->dev.parent);
if (!handle)
return;
Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
+++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -182,7 +182,6 @@ static int dw_i2c_probe(struct platform_
adap->algo = _dw_algo;
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;
- ACPI_HANDLE_SET(>dev, ACPI_HANDLE(>dev));
r = i2c_add_numbered_adapter(adap);
if (r) {
--
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] ACPI / SPI: Use parent's ACPI_HANDLE() in acpi_register_spi_devices()
From: Rafael J. Wysocki The ACPI handle of struct spi_master's dev member should not be set, because this causes that struct spi_master to be associated with the ACPI device node corresponding to its parent as the second "physical_device", which is incorrect (this happens during the registration of struct spi_master). Consequently, acpi_register_spi_devices() should use the ACPI handle of the parent of the struct spi_master it is called for rather than that struct spi_master's ACPI handle (which should be NULL). Make that happen and modify the spi-pxa2xx driver, which currently is the only driver for ACPI-enumerated SPI controller chips, not to set the ACPI handle for the struct spi_master it creates. Signed-off-by: Rafael J. Wysocki --- drivers/spi/spi-pxa2xx.c |1 - drivers/spi/spi.c|2 +- 2 files changed, 1 insertion(+), 2 deletions(-) Index: linux-pm/drivers/spi/spi.c === --- linux-pm.orig/drivers/spi/spi.c +++ linux-pm/drivers/spi/spi.c @@ -984,7 +984,7 @@ static void acpi_register_spi_devices(st acpi_status status; acpi_handle handle; - handle = ACPI_HANDLE(>dev); + handle = ACPI_HANDLE(master->dev.parent); if (!handle) return; Index: linux-pm/drivers/spi/spi-pxa2xx.c === --- linux-pm.orig/drivers/spi/spi-pxa2xx.c +++ linux-pm/drivers/spi/spi-pxa2xx.c @@ -1168,7 +1168,6 @@ static int pxa2xx_spi_probe(struct platf master->dev.parent = >dev; master->dev.of_node = pdev->dev.of_node; - ACPI_HANDLE_SET(>dev, ACPI_HANDLE(>dev)); /* the spi->mode bits understood by this driver: */ master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP; -- 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] posix-timers: Correctly get dying task time sample in posix_cpu_timer_schedule()
On 2013年03月30日 21:15, Frederic Weisbecker wrote: > In order to arm the next timer to schedule, we take a sample of the > current process or thread cputime. > > If the task is dying though, we don't arm anything but we > cache the remaining timer expiration delta for further reads. > > Something similar is performed in posix_cpu_timer_get() but > here we forget to take the process wide cputime sample > before caching it. > > As a result we are storing random stack content, leading > every further reads of that timer to return junk values. > > Fix this by taking the appropriate sample in the case of > process wide timers. > > Reported-by: Andrew Morton > Reported-by: Chen Gang > Signed-off-by: Frederic Weisbecker > Cc: Stanislaw Gruszka > Cc: Thomas Gleixner > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Oleg Nesterov > Cc: Chen Gang > --- thank you for mark me as reported by, although I reported too late (Andrew Morton is the first reporter). next, I should continue to try to find another issues about kernel. :-) -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: timer: Shutdown clock event device when stopping local timer
On 03/29/2013 10:24 AM, ning.n.ji...@gmail.com wrote:
> From: Ning Jiang
>
> Currently there are two problems when we try to stop local timer.
> First, it calls set_mode function directly so mode state is not
> updated for the clock event device. Second, it makes the device
> unused instead of shutdown.
>
> A subtle error will happen because of it. When a cpu is plugged out
> it will stop the local timer. It will call tick_nohz_idle_enter()
> in idle thread afterwards. It will cancel the sched timer and try
> to reprogram the next event. This is wrong since the local timer
> is supposed to be stopped.
>
> The right way to stop the local timer is to shutdown it by calling
> clockevents_set_mode(). Thus when we try to reprogram the clock
> event device, it will return directly without doing anything since
> the clock mode is CLOCK_EVT_MODE_SHUTDOWN.
>
> Signed-off-by: Ning Jiang
> ---
Don't you see a kernel BUG with this patch ?
In the clockevents code, there is:
/**
* clockevents_notify - notification about relevant events
*/
void clockevents_notify(unsigned long reason, void *arg)
{
...
case CLOCK_EVT_NOTIFY_CPU_DEAD:
...
cpu = *((int *)arg);
list_for_each_entry_safe(dev, tmp, _devices,
list) {
if (cpumask_test_cpu(cpu, dev->cpumask) &&
cpumask_weight(dev->cpumask) == 1 &&
!tick_is_broadcast_device(dev)) {
BUG_ON(dev->mode !=
CLOCK_EVT_MODE_UNUSED);
^^
list_del(>list);
}
}
break;
...
}
This is called triggered from hrtimer_cpu_notify with the CPU_DEAD event.
--
Facebook |
Twitter |
[PATCH] THP: Use explicit memory barrier
__do_huge_pmd_anonymous_page depends on page_add_new_anon_rmap's spinlock for making sure that clear_huge_page write become visible after set set_pmd_at() write. But lru_cache_add_lru uses pagevec so it could miss spinlock easily so above rule was broken so user may see inconsistent data. This patch fixes it with using explict barrier rather than depending on lru spinlock. Cc: Mel Gorman Cc: Andrea Arcangeli Cc: Hugh Dickins Signed-off-by: Minchan Kim --- mm/huge_memory.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index bfa142e..fad800e 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -725,11 +725,10 @@ static int __do_huge_pmd_anonymous_page(struct mm_struct *mm, pmd_t entry; entry = mk_huge_pmd(page, vma); /* -* The spinlocking to take the lru_lock inside -* page_add_new_anon_rmap() acts as a full memory -* barrier to be sure clear_huge_page writes become -* visible after the set_pmd_at() write. +* clear_huge_page write become visible after the +* set_pmd_at() write. */ + smp_wmb(); page_add_new_anon_rmap(page, vma, haddr); set_pmd_at(mm, haddr, pmd, entry); pgtable_trans_huge_deposit(mm, pgtable); -- 1.8.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] sparc: Use generic idle loop
From: Sam Ravnborg Date: Fri, 29 Mar 2013 21:29:26 +0100 > Add generic cpu_idle support > > sparc32: > - replace call to cpu_idle() with cpu_startup_entry() > - add arch_cpu_idle() > > sparc64: > - smp_callin() includes cpu_startup_entry() call so we can > skip calling cpu_idle from assembler > - add arch_cpu_idle_enter() and arch_cpu_idle_dead() > > Signed-off-by: Sam Ravnborg Acked-by: David S. Miller -- 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] DM9000B: driver initialization upgrade
From: Joseph CHANG Date: Fri, 29 Mar 2013 17:13:42 +0800 > Fix bug for DM9000 revision B which contain a DSP PHY > > DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY, > So need extra change in initialization, For > explicity PHY Reset and PHY init parameter, and > first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe(). > > Following DM9000_NCR reset cause by dm9000_open() clear the > NCR_MAC_LBK bit. > > Without this fix, Power-up FIFO pointers error happen around 2% > rate among Davicom's customers' boards. With this fix, All above > cases can be solved. > > Signed-off-by: Joseph CHANG Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: timer: Shutdown clock event device when stopping local timer
On 03/29/2013 10:24 AM, ning.n.ji...@gmail.com wrote:
> From: Ning Jiang
>
> Currently there are two problems when we try to stop local timer.
> First, it calls set_mode function directly so mode state is not
> updated for the clock event device. Second, it makes the device
> unused instead of shutdown.
>
> A subtle error will happen because of it. When a cpu is plugged out
> it will stop the local timer. It will call tick_nohz_idle_enter()
> in idle thread afterwards. It will cancel the sched timer and try
> to reprogram the next event. This is wrong since the local timer
> is supposed to be stopped.
>
> The right way to stop the local timer is to shutdown it by calling
> clockevents_set_mode(). Thus when we try to reprogram the clock
> event device, it will return directly without doing anything since
> the clock mode is CLOCK_EVT_MODE_SHUTDOWN.
>
> Signed-off-by: Ning Jiang
> ---
> arch/arm/kernel/smp_twd.c|2 +-
> arch/arm/mach-exynos/mct.c |2 +-
> arch/arm/mach-msm/timer.c|2 +-
> drivers/clocksource/arm_arch_timer.c |2 +-
> drivers/clocksource/time-armada-370-xp.c |2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index 3f25650..c1d4ab4 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -92,7 +92,7 @@ static int twd_timer_ack(void)
>
> static void twd_timer_stop(struct clock_event_device *clk)
> {
> - twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
> + clockevents_set_mode(clk, CLOCK_EVT_MODE_SHUTDOWN);
> disable_percpu_irq(clk->irq);
Wouldn't be clockevents_shutdown more adequate here ? The next event
will be also set.
--
Facebook |
Twitter |
Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
Hi! > >>User wants to test for a file with name "foo.txt" > >> > >>* create "foo.txt~" (or whatever) > >>* write contents into "foo.txt~" > >>* rename "foo.txt~" to "foo.txt" > >> > >>Until rename is done, the file does not exists and is not complete. > >>You will potentially have a garbage file to clean up if the program > >>(or system) crashes, but that is not racy in a classic sense, right? > >Well. If people rsync from you, they will start fetching incomplete > >foo.txt~. Plus the garbage issue. > > That is not racy, just garbage (not trying to be pedantic, just > trying to understand). I can see that the "~" file is annoying, but > we have dealt with it for a *long* time :) Ok, so lets keep it at "~" is annoying :-). [But... I was wrong. openat(..., AT_UNLINKED) is not enough to solve this: we do not have flink() and it is not easily possible to link deleted file "back to life" from /proc/self/fd: pavel@amd:/tmp$ > delme pavel@amd:/tmp$ bash 3< delme & [2] 32667 [2]+ Stopped bash 3< delme pavel@amd:/tmp$ fg bash 3< delme pavel@amd:/tmp$ ls -al delme -rw-r--r-- 1 pavel pavel 0 Apr 1 01:36 delme pavel@amd:/tmp$ ls -al /proc/self/fd/3 lr-x-- 1 pavel pavel 64 Apr 1 01:37 /proc/self/fd/3 -> /tmp/delme pavel@amd:/tmp$ rm delme pavel@amd:/tmp$ ls -al /proc/self/fd/3 lr-x-- 1 pavel pavel 64 Apr 1 01:37 /proc/self/fd/3 -> /tmp/delme (deleted) pavel@amd:/tmp$ ln /proc/self/fd/3 delme2 ln: creating hard link `delme2' => `/proc/self/fd/3': Invalid cross-device link ] > >>This is more of a garbage clean up issue? > >Also. Plus sometimes you want temporary "file" that is > >deleted. Terminals use it for history, etc... > > There you would have a race, you can create a file and unlink it of > course and still write to it, but you would have a potential empty > file issue? Yes. openat(..., AT_UNLINKED) solves that -- you'll no longer get those files. (Not sure they'd be always empty. How do you ensure rm hits the disk? fsync() on parent directory? Sounds expensive.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] sparc:cleanup unused code in smp_32.h
From: Kefeng Wang Date: Sat, 30 Mar 2013 18:28:26 +0800 > After genirq and generic clockevent support at sparc32, > smp4m_irq_rotate(), prof_multiplier() and prof_counter() > are no longer used and should be removed. > > Find more info from commit 6baa9b20 & 62f08283. > > Signed-off-by: Kefeng Wang Applied. -- 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] sparc:remove unused declaration smp_boot_cpus()
From: Sam Ravnborg Date: Fri, 29 Mar 2013 12:09:04 +0100 > On Wed, Mar 27, 2013 at 08:20:45PM +0800, Kefeng Wang wrote: >> smp_boot_cpus() was replaced smp_prepare_cpus() long ago, and it no >> longer needed, so delete it. >> >> Signed-off-by: Kefeng Wang > Acked-by: Sam Ravnborg Applied. -- 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: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
On 03/31/2013 07:18 PM, Pavel Machek wrote: Hi! Take a look at how many actively used filesystems out there that have some variant of sillyrename(), and explain what you want to do in those cases. Well. Yes, there are non-unix filesystems around. You have to deal with silly files on them, and this will not be different. So this would be a local POSIX filesystem only solution to a problem that has yet to be formulated? Problem is "clasical create temp file then delete it" is racy. See the archives. That is useful & common operation. Which race are you concerned with exactly? User wants to test for a file with name "foo.txt" * create "foo.txt~" (or whatever) * write contents into "foo.txt~" * rename "foo.txt~" to "foo.txt" Until rename is done, the file does not exists and is not complete. You will potentially have a garbage file to clean up if the program (or system) crashes, but that is not racy in a classic sense, right? Well. If people rsync from you, they will start fetching incomplete foo.txt~. Plus the garbage issue. That is not racy, just garbage (not trying to be pedantic, just trying to understand). I can see that the "~" file is annoying, but we have dealt with it for a *long* time :) Until it has the right name (on either the source or target system for rsync), it is not the file you are looking for. This is more of a garbage clean up issue? Also. Plus sometimes you want temporary "file" that is deleted. Terminals use it for history, etc... There you would have a race, you can create a file and unlink it of course and still write to it, but you would have a potential empty file issue? Ric -- 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: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
Hi! > Take a look at how many actively used filesystems out there that have > some variant of sillyrename(), and explain what you want to do in those > cases. > >>>Well. Yes, there are non-unix filesystems around. You have to deal > >>>with silly files on them, and this will not be different. > >>So this would be a local POSIX filesystem only solution to a problem > >>that has yet to be formulated? > >Problem is "clasical create temp file then delete it" is racy. See the > >archives. That is useful & common operation. > > Which race are you concerned with exactly? > > User wants to test for a file with name "foo.txt" > > * create "foo.txt~" (or whatever) > * write contents into "foo.txt~" > * rename "foo.txt~" to "foo.txt" > > Until rename is done, the file does not exists and is not complete. > You will potentially have a garbage file to clean up if the program > (or system) crashes, but that is not racy in a classic sense, right? Well. If people rsync from you, they will start fetching incomplete foo.txt~. Plus the garbage issue. > This is more of a garbage clean up issue? Also. Plus sometimes you want temporary "file" that is deleted. Terminals use it for history, etc... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
Internal mic doesn't work on Dell Vostro 3360
Hi. I've got Dell Vostro 3360 laptop, and internal mic doesn't work. I use 3.8 series kernel. When I try to record sound from mic I get only weird noise. All sliders in alsamixer are 100% and capture is ON. alsa-info.sh script output could be found here: https://gist.github.com/a043fcf2686076d3e48f I guess it could be fixed by specifying model for snd-hda-intel module but I've got no idea what model I should specify. Takashi, could you help me? Regards, Oleksandr. signature.asc Description: This is a digitally signed message part.
Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
On 03/31/2013 06:50 PM, Pavel Machek wrote:
On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote:
On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote:
Hmm. open_deleted_file() will still need to get a directory... so it
will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would
be acceptable interface?
...and what's the big plan to make this work on anything other than ext4 and
btrfs?
Deleted but open files are from original unix, so it should work on
anything unixy (minix, ext, ext2, ...).
minix, ext, ext2... are not under active development and haven't been
for more than a decade.
Take a look at how many actively used filesystems out there that have
some variant of sillyrename(), and explain what you want to do in those
cases.
Well. Yes, there are non-unix filesystems around. You have to deal
with silly files on them, and this will not be different.
So this would be a local POSIX filesystem only solution to a problem
that has yet to be formulated?
Problem is "clasical create temp file then delete it" is racy. See the
archives. That is useful & common operation.
Which race are you concerned with exactly?
User wants to test for a file with name "foo.txt"
* create "foo.txt~" (or whatever)
* write contents into "foo.txt~"
* rename "foo.txt~" to "foo.txt"
Until rename is done, the file does not exists and is not complete. You will
potentially have a garbage file to clean up if the program (or system) crashes,
but that is not racy in a classic sense, right?
This is more of a garbage clean up issue?
Regards,
Ric
Problem is "atomicaly create file at target location with guaranteed
right content". That's also in the archives. Looks useful if someone
does rsync from your directory.
Non-POSIX filesystems have problems handling deleted files, but that
was always the case. That's one of the reasons they are seldomly used
for root filesystems.
Pavel
--
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: [char-misc-next 08/11 V5] mei: nfc: Initial nfc implementation
On Mon, Apr 01, 2013 at 12:49:49AM +0200, Samuel Ortiz wrote: > Hi Greg, > > On Fri, Mar 29, 2013 at 08:48:23AM -0700, Greg KH wrote: > > On Wed, Mar 27, 2013 at 05:30:00PM +0200, Tomas Winkler wrote: > > > --- /dev/null > > > +++ b/drivers/misc/mei/nfc.h > > > @@ -0,0 +1,122 @@ > > > +/** > > > + * Intel Management Engine Interface (Intel MEI) Linux driver > > > + * Intel MEI Interface Header > > > + * > > > + * This file is provided under a dual BSD/GPLv2 license. When using or > > > + * redistributing this file, you may do so under either license. > > > + * > > > + * GPL LICENSE SUMMARY > > > + * > > > + * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved. > > > + * > > > + * This program is free software; you can redistribute it and/or modify > > > + * it under the terms of version 2 of the GNU General Public License as > > > + * published by the Free Software Foundation. > > > + * > > > + * This program is distributed in the hope that it will be useful, but > > > + * WITHOUT ANY WARRANTY; without even the implied warranty of > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > > + * General Public License for more details. > > > + * > > > + * You should have received a copy of the GNU General Public License > > > + * along with this program; if not, write to the Free Software > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110, > > > + * USA > > > + * > > > + * The full GNU General Public License is included in this distribution > > > + * in the file called LICENSE.GPL. > > > + * > > > + * Contact Information: > > > + * Intel Corporation. > > > + * linux-...@linux.intel.com > > > + * http://www.intel.com > > > + * > > > + * BSD LICENSE > > > + * > > > + * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved. > > > + * All rights reserved. > > > + * > > > + * Redistribution and use in source and binary forms, with or without > > > + * modification, are permitted provided that the following conditions > > > + * are met: > > > + * > > > + * * Redistributions of source code must retain the above copyright > > > + *notice, this list of conditions and the following disclaimer. > > > + * * Redistributions in binary form must reproduce the above copyright > > > + *notice, this list of conditions and the following disclaimer in > > > + *the documentation and/or other materials provided with the > > > + *distribution. > > > + * * Neither the name Intel Corporation nor the names of its > > > + *contributors may be used to endorse or promote products derived > > > + *from this software without specific prior written permission. > > > + * > > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > > > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > > > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > > > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > > > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > > > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > > > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > > > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > > > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > > > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > > > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > > + * > > > + > > > */ > > > > How is your .h file dual licensed, and yet, the .c file is gpl2 only? > > > > Please fix this by not even having this .h file, it's not needed. > The structures and commands defined in nfc.h may be used by pure userspace NFC > stacks (e.g. the Android ones) and I don't want them to be defined under a GPL > only license (Even though some will say structure and command definitions are > not copyrighteable). The law says that structures and command definitions are not copyrightable, Oracle hasn't overturned that one yet. That explains how the BSDs now have the kobject api taken from Linux with no issues at all. > Would it be fine with you if I'd put those definitions under > include/uapi/linux/mei.h ? No, just put them in the driver itself, there is no need for them to be in a .h file at all. 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/
[PATCH 2/2] PM / QoS: Avoid possible deadlock related to sysfs access
From: Rafael J. Wysocki
Commit b81ea1b (PM / QoS: Fix concurrency issues and memory leaks in
device PM QoS) put calls to pm_qos_sysfs_add_latency(),
pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a
mistake, because it may lead to deadlocks in some situations.
For example, if pm_qos_remote_wakeup_store() is run in parallel
with dev_pm_qos_constraints_destroy(), they may deadlock in the
following way:
==
[ INFO: possible circular locking dependency detected ]
3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: GW
---
trinity-child6/12371 is trying to acquire lock:
(s_active#54){.+}, at: [] sysfs_addrm_finish+0x31/0x60
but task is already holding lock:
(dev_pm_qos_mtx){+.+.+.}, at: []
dev_pm_qos_constraints_destroy+0x23/0x250
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (dev_pm_qos_mtx){+.+.+.}:
[] lock_acquire+0x1aa/0x240
[] __mutex_lock_common+0x59/0x5e0
[] mutex_lock_nested+0x3f/0x50
[] dev_pm_qos_update_flags+0x3f/0xc0
[] pm_qos_remote_wakeup_store+0x3f/0x70
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xfa/0x150
[] __kernel_write+0x81/0x150
[] write_pipe_buf+0x4d/0x80
[] splice_from_pipe_feed+0x7c/0x120
[] __splice_from_pipe+0x45/0x80
[] splice_from_pipe+0x4c/0x70
[] default_file_splice_write+0x18/0x30
[] do_splice_from+0x83/0xb0
[] direct_splice_actor+0x1e/0x20
[] splice_direct_to_actor+0xe7/0x200
[] do_splice_direct+0x4c/0x70
[] do_sendfile+0x169/0x300
[] SyS_sendfile64+0x64/0xb0
[] tracesys+0xe1/0xe6
-> #0 (s_active#54){.+}:
[] __lock_acquire+0x15bf/0x1e50
[] lock_acquire+0x1aa/0x240
[] sysfs_deactivate+0x122/0x1a0
[] sysfs_addrm_finish+0x31/0x60
[] sysfs_hash_and_remove+0x7f/0xb0
[] sysfs_unmerge_group+0x51/0x70
[] pm_qos_sysfs_remove_flags+0x14/0x20
[] __dev_pm_qos_hide_flags+0x30/0x70
[] dev_pm_qos_constraints_destroy+0x35/0x250
[] dpm_sysfs_remove+0x11/0x50
[] device_del+0x3f/0x1b0
[] device_unregister+0x48/0x60
[] usb_hub_remove_port_device+0x1c/0x20
[] hub_disconnect+0xdd/0x160
[] usb_unbind_interface+0x67/0x170
[] __device_release_driver+0x87/0xe0
[] device_release_driver+0x29/0x40
[] bus_remove_device+0x148/0x160
[] device_del+0x14f/0x1b0
[] usb_disable_device+0xf9/0x280
[] usb_set_configuration+0x268/0x840
[] usb_remove_store+0x4c/0x80
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xfa/0x150
[] do_loop_readv_writev+0x4d/0x90
[] do_readv_writev+0xf9/0x1e0
[] vfs_writev+0x3a/0x60
[] SyS_writev+0x50/0xd0
[] tracesys+0xe1/0xe6
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(dev_pm_qos_mtx);
lock(s_active#54);
lock(dev_pm_qos_mtx);
lock(s_active#54);
*** DEADLOCK ***
To avoid that, remove the calls to functions mentioned above from
under dev_pm_qos_mtx and introduce a separate lock to prevent races
between functions that add or remove device PM QoS sysfs attributes
from happening.
Reported-by: Sasha Levin
Signed-off-by: Rafael J. Wysocki
---
drivers/base/power/qos.c | 60 ---
1 file changed, 47 insertions(+), 13 deletions(-)
Index: linux-pm/drivers/base/power/qos.c
===
--- linux-pm.orig/drivers/base/power/qos.c
+++ linux-pm/drivers/base/power/qos.c
@@ -46,6 +46,7 @@
#include "power.h"
static DEFINE_MUTEX(dev_pm_qos_mtx);
+static DEFINE_MUTEX(dev_pm_qos_sysfs_mtx);
static BLOCKING_NOTIFIER_HEAD(dev_pm_notifiers);
@@ -216,12 +217,17 @@ void dev_pm_qos_constraints_destroy(stru
struct pm_qos_constraints *c;
struct pm_qos_flags *f;
- mutex_lock(_pm_qos_mtx);
+ mutex_lock(_pm_qos_sysfs_mtx);
/*
* If the device's PM QoS resume latency limit or PM QoS flags have been
* exposed to user space, they have to be hidden at this point.
*/
+ pm_qos_sysfs_remove_latency(dev);
+ pm_qos_sysfs_remove_flags(dev);
+
+ mutex_lock(_pm_qos_mtx);
+
__dev_pm_qos_hide_latency_limit(dev);
__dev_pm_qos_hide_flags(dev);
@@ -254,6 +260,8 @@ void dev_pm_qos_constraints_destroy(stru
out:
mutex_unlock(_pm_qos_mtx);
+
+ mutex_unlock(_pm_qos_sysfs_mtx);
}
/**
@@ -558,6 +566,14 @@ static void __dev_pm_qos_drop_user_reque
[PATCH 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)
On Sunday, March 31, 2013 03:41:11 AM Rafael J. Wysocki wrote: > [Moving the thread to the LKML.] > > On Saturday, March 30, 2013 06:41:16 PM Sasha Levin wrote: > > On 03/15/2013 01:06 PM, Rafael J. Wysocki wrote: > [...] > > >> Rafael, Is there anything you would like me to test? > > > > > > Please just test 3.9-rc2 (or later). > > > > Hi Rafael, > > Hi, > > > I got this after a bit of fuzzing, it looks related to the fix: > > So the complaint is that we shouldn't call pm_qos_sysfs_remove_flags() under > dev_pm_qos_mtx, because then it may deadlock with dev_pm_qos_update_flags() > called from pm_qos_remote_wakeup_store(), for example. This appears to be a > valid one. > > To avoid that, we can use a separate mutex for exposing/hiding the flags > (and the latency limit too) that won't be acquired by > dev_pm_qos_update_flags() > or dev_pm_qos_update_request(). > > Can you please try the patch below? Never mind, I have reproduced the lockdep splat and the patch fixes it for me. Moreover, I've discovered that we call dev_pm_qos_hide_flags() from usb_port_device_release(), which is totally incorrect. So, I have two patches (on top of the Linus' tree) that will follow shortly: [1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release() [2/2] PM / QoS: Avoid possible deadlock related to sysfs access Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()
From: Rafael J. Wysocki
Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
"usb: Add driver/usb/core/(port.c,hub.h) files", from
usb_port_device_release(), because (1) it is completely unnecessary
(the flags have been removed already by the PM core during the
unregistration of the device object) and (2) it triggers a NULL
pointer dereference in sysfs_find_dirent() (dev->kobj->sd is NULL at
this point).
Signed-off-by: Rafael J. Wysocki
---
drivers/usb/core/port.c |1 -
1 file changed, 1 deletion(-)
Index: linux-pm/drivers/usb/core/port.c
===
--- linux-pm.orig/drivers/usb/core/port.c
+++ linux-pm/drivers/usb/core/port.c
@@ -67,7 +67,6 @@ static void usb_port_device_release(stru
{
struct usb_port *port_dev = to_usb_port(dev);
- dev_pm_qos_hide_flags(dev);
kfree(port_dev);
}
--
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: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote:
> On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote:
> > > > > > Hmm. open_deleted_file() will still need to get a directory... so it
> > > > > > will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED)
> > > > > > would
> > > > > > be acceptable interface?
> > > > >
> > > > > ...and what's the big plan to make this work on anything other than
> > > > > ext4 and btrfs?
> > > >
> > > > Deleted but open files are from original unix, so it should work on
> > > > anything unixy (minix, ext, ext2, ...).
> > >
> > > minix, ext, ext2... are not under active development and haven't been
> > > for more than a decade.
> > >
> > > Take a look at how many actively used filesystems out there that have
> > > some variant of sillyrename(), and explain what you want to do in those
> > > cases.
> >
> > Well. Yes, there are non-unix filesystems around. You have to deal
> > with silly files on them, and this will not be different.
>
> So this would be a local POSIX filesystem only solution to a problem
> that has yet to be formulated?
Problem is "clasical create temp file then delete it" is racy. See the
archives. That is useful & common operation.
Problem is "atomicaly create file at target location with guaranteed
right content". That's also in the archives. Looks useful if someone
does rsync from your directory.
Non-POSIX filesystems have problems handling deleted files, but that
was always the case. That's one of the reasons they are seldomly used
for root filesystems.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [char-misc-next 08/11 V5] mei: nfc: Initial nfc implementation
Hi Greg,
On Fri, Mar 29, 2013 at 08:48:23AM -0700, Greg KH wrote:
> On Wed, Mar 27, 2013 at 05:30:00PM +0200, Tomas Winkler wrote:
> > --- /dev/null
> > +++ b/drivers/misc/mei/nfc.h
> > @@ -0,0 +1,122 @@
> > +/**
> > + * Intel Management Engine Interface (Intel MEI) Linux driver
> > + * Intel MEI Interface Header
> > + *
> > + * This file is provided under a dual BSD/GPLv2 license. When using or
> > + * redistributing this file, you may do so under either license.
> > + *
> > + * GPL LICENSE SUMMARY
> > + *
> > + * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of version 2 of the GNU General Public License as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110,
> > + * USA
> > + *
> > + * The full GNU General Public License is included in this distribution
> > + * in the file called LICENSE.GPL.
> > + *
> > + * Contact Information:
> > + * Intel Corporation.
> > + * linux-...@linux.intel.com
> > + * http://www.intel.com
> > + *
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved.
> > + * All rights reserved.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + *
> > + * * Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in
> > + *the documentation and/or other materials provided with the
> > + *distribution.
> > + * * Neither the name Intel Corporation nor the names of its
> > + *contributors may be used to endorse or promote products derived
> > + *from this software without specific prior written permission.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + *
> > +
> > */
>
> How is your .h file dual licensed, and yet, the .c file is gpl2 only?
>
> Please fix this by not even having this .h file, it's not needed.
The structures and commands defined in nfc.h may be used by pure userspace NFC
stacks (e.g. the Android ones) and I don't want them to be defined under a GPL
only license (Even though some will say structure and command definitions are
not copyrighteable). Would it be fine with you if I'd put those definitions
under include/uapi/linux/mei.h ?
> > +struct mei_nfc_cmd {
> > + uint8_t command;
> > + uint8_t status;
> > + uint16_t req_id;
> > + uint32_t reserved;
> > + uint16_t data_size;
> > + uint8_t sub_command;
> > + uint8_t data[];
> > +} __packed;
>
> Use "real" Linux kernel data types, not these cruddy userspace ones
> (i.e. u8, u16, etc.)
Will fix that.
> I've applied the patches prior to this in the series and stopped here,
Thanks.
> so feel free to redo the rest of them and resend.
I will do so in the next days.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kbuild: avoid rebuild of file2alias for each build
When introducing devicetable-offsets generation this
had the side-effect that file2alias (and thus modpost)
were build for each kernel build.
devicetable-offsets were introduced in 6543becf26fff612cdadeed7250ccc8d49f67f27
("mod/file2alias: make modalias generation safe for cross compiling")
"make V=2" said this was due to target not included in targets.
So add devicetable-offsets to targets.
Signed-off-by: Sam Ravnborg
---
diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile
index 9415b56..c8e04e9 100644
--- a/scripts/mod/Makefile
+++ b/scripts/mod/Makefile
@@ -30,10 +30,12 @@ define cmd_offsets
endef
# We use internal kbuild rules to avoid the "is up to date" message from make
+targets += devicetable-offsets.s
scripts/mod/devicetable-offsets.s: scripts/mod/devicetable-offsets.c FORCE
$(Q)mkdir -p $(dir $@)
$(call if_changed_dep,cc_s_c)
+targets += $(devicetable-offsets-file)
$(obj)/$(devicetable-offsets-file): scripts/mod/devicetable-offsets.s
$(call cmd,offsets)
--
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: New copyfile system call - discuss before LSF?
Pavel Machek wrote: > Eric Wong wrote: > > [1] my splice() annoyances: > > * need to create/manage a pipe > > * copy size limited by pipe size > > * doesn't reduce userspace syscalls (just data copy overhead) > > * easy to misuse and starve with blocking sockets + big buffers > > * not many users, so bugs creep in (v3.7.8 was the first usable > > version of the 3.7 series for TCP sockets) > > Could library be created to make it less annoying to use, and harder > to misuse? Maybe, but getting people to use the library would be the hard, too. And a library would not reduce syscalls in the common case. We already have current->splice_pipe for sendfile, so maybe splice can be taught to transparently use that when neither FD is a pipe. I also think a SPLICE_F_DONTWAIT flag might be necessary. It would be a superset of SPLICE_F_NONBLOCK, but also act like MSG_DONTWAIT for the non-pipe socket. > splice man page does not mention pipe size limit... It probably should. I think I discovered it by using it many years ago and burned it into my mind. -- 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/
Freescale FEC: fall back to random address
If there's no valid ethernet address, fall back to randomly generated
one.
(Yes, I need to get newer u-boot for the board, but as the only
available one is from 2009... this might be good idea).
Signed-off-by: Pavel Machek
index e3f3937..5a7d1e1 100644
pp--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -906,6 +914,16 @@ static void fec_get_mac(struct net_device *ndev)
iap = [0];
}
+ /*
+* 5) random mac address
+*/
+ if (!is_valid_ether_addr(iap)) {
+ /* Report it and use a random ethernet address instead */
+ netdev_err(ndev, "Invalid MAC address: %pM\n", iap);
+ random_ether_addr(iap);
+ netdev_info(ndev, "Using random MAC address: %pM\n", iap);
+ }
+
memcpy(ndev->dev_addr, iap, ETH_ALEN);
/* Adjust MAC if using macaddr */
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v7 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver
On Sat, Mar 30, 2013 at 04:27:26PM -0700, Guenter Roeck wrote: > > > > Each of ST-Ericsson X500 chip set series consists of both ABX500 and > > > > DBX500 > > > > chips. This is ABX500 hwmon driver, where the abx500.c is a common > > > > layer for > > > > all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this > > > > designed > > > > structure, other chip specific files can be added simply using the same > > > > common > > > > layer abx500.c. > > > > > > > > Signed-off-by: Hongbo Zhang > > > > > > Reviewed-by: Guenter Roeck > > > > Thanks a lot for your reviews, Guenter! > > > > Guenter, Jean, > > > > As the driver depends on the battery driver changes, do you mind if I take > > it via battery-2.6.git tree? > > Ok with me. I actually assumed it would be merged through another tree because > of its dependencies. Great, thanks a lot! Hongbo, so can you please rebase the patches onto battery-2.6.git[1] tree so that I could apply them? Thanks, Anton [1] http://git.infradead.org/battery-2.6.git -- 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] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r
On Thu, 21 Mar 2013, Daniel Vetter wrote: > Indeed, this is pretty useful and allowed me to quickly reproduce that > phantom irq on my gm45. Thanks to module reloading we can even reset the > kernel's irq disabling logic and so test different tricks quickly without > rebooting. Really useful. Daniel, out of curiosity, have you been able to make some sense of the phantom legacy IRQs on GM45 systems, or are we just staying with my original bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gpio-ucb1400
Dear Guenter Roeck, > On Sat, Mar 30, 2013 at 08:20:44PM +0100, Marek Vasut wrote: > > Dear Guenter Roeck, > > > > > On Fri, Mar 29, 2013 at 08:46:39PM +0100, Jean Delvare wrote: > > > > Hi all, > > > > > > > > In September 2009, a driver for the GPIO function of the UCB1400 chip > > > > was added to the kernel tree. The probe function of this driver > > > > requires ucbdata to be set. The only place where this happens is in > > > > function ucb1400_gpio_set_data(). This function was never call, and > > > > still isn't. So this is dead code for 3.5 years as far as the > > > > upstream kernel is concerned. > > > > > > > > To make things worse, this driver can't be built as a module, for no > > > > good reason that I can see. > > > > > > > > Marek, can you explain what was the point of submitting this driver > > > > that nobody can use? > > > > > > > > I would like either this driver to be fixed so that it can be used > > > > (and that would IMHO start with dropping the ugly > > > > ucb1400_gpio_set_data hook and global variable ucbdata), or this > > > > driver to be dropped from the kernel tree. If the driver is kept, it > > > > should be adjusted so that it can be built as a module. > > > > > > > > If I overlooked something, please let me know. > > > > > > Interestingly, the author made an attempt to fix that with [1]. It > > > looks like the rest of that series was merged, but this patch wasn't, > > > though I don't find any information about the reason. > > > > It's been a while. Guenter, thanks for finding that link, but I suspect > > the patch is heavily obsolete by now. > > Oh, it most definitely is, starting with the gpio driver name. Just wonder > why it was never applied, and why no one seems to have noticed or cared. > > Jean is absolutely right - it should get fixed, or the driver should be > dropped if no one is using it anyway. I think ARM/palmtc was using this. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 13/14] workqueue: implement NUMA affinity for unbound workqueues
Hello, Lai. On Sun, Mar 31, 2013 at 01:23:46AM +0800, Lai Jiangshan wrote: > But for unbound wq when cpuhotplug > w/o NUMA affinity, works arealways in the cpus if there is online > cpu in wq's cpumask > w/ NUMA affinity, . NOT always even > Yeah, this is rather unfortunate but cpumask for unbound workqueue is a completely new thing anyway and I think providing a similar guarantee as per-cpu should be enough. Things are much simpler that way and requiring users which depend on hard affinity to take care of flushing is reasonable enough and in line with how workqueue has traditionally been working. > > Workqueue's affinity guarantee is very specific - the work item owner is > > responsible for flushing the work item during CPU DOWN if it wants > > to guarantee affinity over full execution. > > Could you add the comments and add Reviewed-by: Lai Jiangshan > > for the patchset? Sure thing. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote:
> > > > > Hmm. open_deleted_file() will still need to get a directory... so it
> > > > > will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would
> > > > > be acceptable interface?
> > > >
> > > > ...and what's the big plan to make this work on anything other than
> > > > ext4 and btrfs?
> > >
> > > Deleted but open files are from original unix, so it should work on
> > > anything unixy (minix, ext, ext2, ...).
> >
> > minix, ext, ext2... are not under active development and haven't been
> > for more than a decade.
> >
> > Take a look at how many actively used filesystems out there that have
> > some variant of sillyrename(), and explain what you want to do in those
> > cases.
>
> Well. Yes, there are non-unix filesystems around. You have to deal
> with silly files on them, and this will not be different.
So this would be a local POSIX filesystem only solution to a problem
that has yet to be formulated?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?
> > > > Hmm. open_deleted_file() will still need to get a directory... so it
> > > > will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would
> > > > be acceptable interface?
> > >
> > > ...and what's the big plan to make this work on anything other than ext4
> > > and btrfs?
> >
> > Deleted but open files are from original unix, so it should work on
> > anything unixy (minix, ext, ext2, ...).
>
> minix, ext, ext2... are not under active development and haven't been
> for more than a decade.
>
> Take a look at how many actively used filesystems out there that have
> some variant of sillyrename(), and explain what you want to do in those
> cases.
Well. Yes, there are non-unix filesystems around. You have to deal
with silly files on them, and this will not be different.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
On Saturday 30 March 2013, Arnd Bergmann wrote: > > > In V3: > > > -Detailed commit message added here about why this patch is required. > > > -Eliminated ehci_spear_setup routine beacuse hcd registers > > > directly setting in spear_ehci_hcd_drv_probe function. > > > > Fix the grammar, please. > > Done. I agree some of this is hardly legible. > I realized later that the other patches have similarly screwed up changelogs. I'll send a new version once you've commented on v4, so in case there is anything else I missed I'm not spamming everyone another time. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New copyfile system call - discuss before LSF?
On Sun, 2013-03-31 at 09:36 +0200, Pavel Machek wrote:
> Hi!
>
> > >>> Hmm, really? AFAICT it would be simple to provide an
> > >>> open_deleted_file("directory") syscall. You'd open_deleted_file(),
> > >>> copy source file into it, then fsync(), then link it into filesystem.
> > >>>
> > >>> That should have atomicity properties reflected.
> > >>
> > >> Actually, the open_deleted_file() syscall is quite useful for many
> > >> different things all by itself. Lots of applications need to create
> > >> temporary files that are unlinked at application failure (without a
> > >> race if app crashes after creating the file, but before unlinking).
> > >> It also avoids exposing temporary files into the namespace if other
> > >> applications are accessing the directory.
> > >
> > > Hmm. open_deleted_file() will still need to get a directory... so it
> > > will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would
> > > be acceptable interface?
> >
> > ...and what's the big plan to make this work on anything other than ext4
> > and btrfs?
>
> Deleted but open files are from original unix, so it should work on
> anything unixy (minix, ext, ext2, ...).
> Pavel
minix, ext, ext2... are not under active development and haven't been
for more than a decade.
Take a look at how many actively used filesystems out there that have
some variant of sillyrename(), and explain what you want to do in those
cases.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/4] block: queue work on unbound wq
Hello, Viresh. On Sun, Mar 31, 2013 at 08:01:46PM +0530, Viresh Kumar wrote: > Block layer uses workqueues for multiple purposes. There is no real dependency > of scheduling these on the cpu which scheduled them. > > On a idle system, it is observed that and idle cpu wakes up many times just to > service this work. It would be better if we can schedule it on a cpu which the > scheduler believes to be the most appropriate one. > > This patch replaces normal workqueues with UNBOUND versions. Hmm so, we really don't want to unconditionally convert workqueues to unbound. Especially not kblockd. On configurations with multiple high iops devices with IRQ routing, having request completion runinng on the same CPU has significant performance advantages. We can't simply switch it to an unbound wokrqueue because it saves power on small arm configuration. Plus, I'd much prefer to be clearly marking the workqueues which would contribute to powersaving when converted to unbound at least until we can come up with a no-compromise solution which doesn't need to trade off between cache locality and powersaving. So, let's please introduce a new flag to mark these workqueues, say, WQ_UNBOUND_FOR_POWER_SAVE or whatever (please come up with a better name) and provide a compile time switch with boot time override. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] slave-dmaengine fixes
Hi Linus, Please pull the following two patches to recive the fixes for slave-dmaengine. The first one is for making slave_id value correct for dw_dmac and send one fixes the endieness in DT parsing The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git fixes Andy Shevchenko (1): dw_dmac: adjust slave_id accordingly to request line base Arnd Bergmann (1): dmaengine: dw_dma: fix endianess for DT xlate function drivers/dma/dw_dmac.c | 23 +++ drivers/dma/dw_dmac_regs.h |1 + 2 files changed, 20 insertions(+), 4 deletions(-) -- ~Vinod signature.asc Description: Digital signature
Re: ipc,sem: sysv semaphore scalability
On Sun, Mar 31, 2013 at 6:45 AM, Rik van Riel wrote: > > Should we use "semid" here, like Linus suggested, instead of "un->semid"? As Davidlohr noted, in linux-next the rcu read-lock is held over the whole thing, so no, un->semid should be stable once "un" has been re-looked-up under the semaphore lock. In mainline, the problem is that the "sem_lock_check()" is done with "un->semid" *after* we've dropped the RCU read-lock, so "un" at that point is not reliable (it could be free'd at any time underneath us). That said, I really *really* hate what both mainline and linux-next do with the RCU read lock, and linux-next is arguably worse. The whole "take the RCU lock in one place, and release it in another" is confusing and bug-prone as hell. And linux-next made it worse: now sem_lock() no longer takes the read-lock (it expects the caller to take it), but sem_unlock() still drops the read-lock. This is all just f*cking crazy. The rule should be that the rcu read-lock is always and released at the same "level". For example, find_alloc_undo() should just be called with (and unconditionaly return with) the rcu read-lock held, and if it needs to actually do an allocation, it can drop the rcu lock for the duration of the allocation. This whole "conditional locking" depending on error returns and on whether we have undo's etc is bug-prone and confusing. And when you have totally different locking rules for "sem_lock()" vs "sem_unlock()", you know you're confused. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ipc,sem: sysv semaphore scalability
Hi Davidlohr, On Sun, Mar 31, 2013 at 12:01 PM, Davidlohr Bueso wrote: > Specially dropping the rcu read lock before the continue statement > (sorry for not mentioning this in the last email). I was missing this indeed, thanks. Still the same issues however... I'll do some more testing on the same machine but with a totally different environment, within tomorrow hopefully. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] Use target compiler for user binaries in samples/
The user-space binaries build in samples/ uses the installed headers for the kernel. Therefore it is wrong that they use the host compiler to build the samples. Following is an attempt to create some infrastructure for building user-space binaries that uses the uapi headers. As my sparc cross toolchain does not supporting building user-space I have not been able to test this as good as I hoped... But faking that my native gcc is a cross gcc seems to work. This adds two new variables to the top-level Makefile: UAPICC and UAPICFLAGS The architectures that supports both 32 and 64 bit set the appropriate flags in UAPICFLAGS. scripts/Makefile.uapiprogs cantains all the infrastructure. I updated the samples for hidraw and seccomp to use the new infrastructure. The file says: +# Sample syntax (see Documentation/kbuild/makefiles.txt for reference) But I did not bother to write this yet - awaiting feedback. Sam Makefile |5 ++ arch/s390/Makefile |2 + arch/sparc/Makefile|2 + arch/x86/Makefile |1 + samples/Makefile |5 ++- samples/hidraw/Makefile| 10 + samples/seccomp/Makefile | 31 +--- scripts/Makefile.build |6 ++- scripts/Makefile.uapiprogs | 88 9 files changed, 109 insertions(+), 41 deletions(-) diff --git a/Makefile b/Makefile index 54d2b2a..b249128 100644 --- a/Makefile +++ b/Makefile @@ -244,6 +244,11 @@ HOSTCXX = g++ HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer HOSTCXXFLAGS = -O2 +UAPICC = $(CROSS_COMPILE)gcc +UAPICFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes +export UAPICC UAPICFLAGS + + # Decide whether to build built-in, modular, or both. # Normally, just do built-in. diff --git a/arch/s390/Makefile b/arch/s390/Makefile index 7e3ce78..7b33550 100644 --- a/arch/s390/Makefile +++ b/arch/s390/Makefile @@ -18,6 +18,7 @@ LD_BFD:= elf32-s390 LDFLAGS:= -m elf_s390 KBUILD_CFLAGS += -m31 KBUILD_AFLAGS += -m31 +UAPICFLAGS += -m31 UTS_MACHINE:= s390 STACK_SIZE := 8192 CHECKFLAGS += -D__s390__ -msize-long @@ -28,6 +29,7 @@ KBUILD_AFLAGS_MODULE += -fPIC KBUILD_CFLAGS_MODULE += -fPIC KBUILD_CFLAGS += -m64 KBUILD_AFLAGS += -m64 +UAPICFLAGS += -m64 UTS_MACHINE:= s390x STACK_SIZE := 16384 CHECKFLAGS += -D__s390__ -D__s390x__ diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile index f489626..dea0dfe 100644 --- a/arch/sparc/Makefile +++ b/arch/sparc/Makefile @@ -28,6 +28,7 @@ UTS_MACHINE:= sparc KBUILD_CFLAGS += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7 KBUILD_AFLAGS += -m32 -Wa,-Av8 +UAPICFLAGS += -m32 else # @@ -44,6 +45,7 @@ KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare KBUILD_CFLAGS += -Wa,--undeclared-regs KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3) KBUILD_AFLAGS += -m64 -mcpu=ultrasparc -Wa,--undeclared-regs +UAPICFLAGS+= -m64 ifeq ($(CONFIG_MCOUNT),y) KBUILD_CFLAGS += -pg diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 5c47726..ee9bcec 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -56,6 +56,7 @@ else KBUILD_AFLAGS += -m64 KBUILD_CFLAGS += -m64 +UAPICFLAGS+= -m64 # Use -mpreferred-stack-boundary=3 if supported. KBUILD_CFLAGS += $(call cc-option,-mno-sse -mpreferred-stack-boundary=3) diff --git a/samples/Makefile b/samples/Makefile index 1a60c62..e463d68 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -1,4 +1,7 @@ # Makefile for Linux samples code +uapiprogs-$(CONFIG_SAMPLES) += hidraw/ +uapiprogs-$(CONFIG_SAMPLES) += seccomp/ + obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ \ - hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ + hw_breakpoint/ kfifo/ kdb/ rpmsg/ diff --git a/samples/hidraw/Makefile b/samples/hidraw/Makefile index 382eeae..a1c18df 100644 --- a/samples/hidraw/Makefile +++ b/samples/hidraw/Makefile @@ -1,10 +1,2 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build -hostprogs-y := hid-example - -# Tell kbuild to always build the programs -always := $(hostprogs-y) - -HOSTCFLAGS_hid-example.o += -I$(objtree)/usr/include +uapiprogs-y := hid-example diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile index 7203e66..0c782bc 100644 --- a/samples/seccomp/Makefile +++ b/samples/seccomp/Makefile @@ -1,42 +1,13 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o -hostprogs-$(CONFIG_SECCOMP_FILTER) := bpf-fancy dropper bpf-direct +uapiprogs-$(CONFIG_SECCOMP_FILTER) := bpf-fancy dropper bpf-direct -HOSTCFLAGS_bpf-fancy.o += -I$(objtree)/usr/include HOSTCFLAGS_bpf-fancy.o += -idirafter $(objtree)/include
Re: [PATCH V4 2/4] PHYLIB: queue work on unbound wq
From: Viresh Kumar Date: Sun, 31 Mar 2013 20:01:45 +0530 > Phylib uses workqueues for multiple purposes. There is no real dependency of > scheduling these on the cpu which scheduled them. > > On a idle system, it is observed that and idle cpu wakes up many times just to > service this work. It would be better if we can schedule it on a cpu which the > scheduler believes to be the most appropriate one. > > This patch replaces system_wq with system_unbound_wq for PHYLIB. > > Cc: David S. Miller > Cc: net...@vger.kernel.org > Signed-off-by: Viresh Kumar Acked-by: David S. Miller -- 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 8/9] spark: cpufreq: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar Date: Sun, 31 Mar 2013 13:00:21 +0530 > On 26 March 2013 09:55, Viresh Kumar wrote: >> From: Viresh Kumar >> Date: Mon, 25 Mar 2013 11:20:23 +0530 >> Subject: [PATCH] sparc: cpufreq: move cpufreq driver to drivers/cpufreq >> >> This patch moves cpufreq driver of SPARC architecture to drivers/cpufreq. >> >> Cc: David S. Miller >> Cc: sparcli...@vger.kernel.org >> Signed-off-by: Viresh Kumar >> --- >> arch/sparc/Kconfig | 23 >> -- >> arch/sparc/kernel/Makefile | 3 --- >> drivers/cpufreq/Kconfig| 23 >> ++ >> drivers/cpufreq/Makefile | 2 ++ >> .../cpufreq/sparc-us2e-cpufreq.c | 0 >> .../cpufreq/sparc-us3-cpufreq.c| 0 >> 6 files changed, 25 insertions(+), 26 deletions(-) >> rename arch/sparc/kernel/us2e_cpufreq.c => >> drivers/cpufreq/sparc-us2e-cpufreq.c (100%) >> rename arch/sparc/kernel/us3_cpufreq.c => >> drivers/cpufreq/sparc-us3-cpufreq.c (100%) > > Hi David, > > Does this one look fine to you? Subject line still has the "spark" typo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/2] watchdog: fix w83627hf_wdt reboot due to timeout expired
On Sun, Mar 31, 2013 at 08:45:54AM -0700, Tony Chung wrote: > How about this? > > - t &= ~0xC0; /* disable keyboard & mouse turning off > - watchdog */ > + t &= ~0xE0; /* clear timeout occurred and disable > keyboard > +& mouse turning off watchdog */ > Ys, only make it 0xD0. Looks like I was fighting with binaries last night and lost. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On 3/14/13 1:57 PM, Pawel Moll wrote: Ok, how about the code below? I must say I have some doubts about the resolution, as there seem to be no generic way of figuring it out for the sched_clock (the arch/arm/kernel/sched_clock.c is actually calculating it, but than just prints it out and nothing more). And, to summarize, we went through 3 ideas: 1. ioctl() - http://article.gmane.org/gmane.linux.kernel/1433933 2. syscall - http://article.gmane.org/gmane.linux.kernel/1437057 3. POSIX clock - below John also suggested that maybe the perf could use CLOCK_MONOTONIC_RAW instead of local/sched_clock(). Any chance a decision can be reached in time for 3.10? Seems like the simplest option is the perf event based ioctl. Converting/correlating perf_clock timestamps to time-of-day is a feature I have been trying to get into perf for over 2 years. This is a big piece needed for that goal -- along with the xtime tracepoints: https://lkml.org/lkml/2013/3/19/433 David -- 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] dmaengine: mpc512x: add slave sg and device control operations
Prepare the driver to support slave sg operation.
For memory to memory transfers mpc_dma_execute() used to start
the transfer explicitely, for peripheral transfers the dma transfer
will be started on peripheral's request, so we only need to enable
peripheral's channel request in mpc_dma_execute().
Signed-off-by: Anatolij Gustschin
---
drivers/dma/mpc512x_dma.c | 150 -
1 files changed, 148 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index bc6c356..1c822b1 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -194,6 +194,9 @@ struct mpc_dma_chan {
/* Lock for this structure */
spinlock_t lock;
+
+ /* Channel's peripheral fifo address */
+ dma_addr_t per_paddr;
};
struct mpc_dma {
@@ -257,7 +260,9 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
prev->tcd->dlast_sga = mdesc->tcd_paddr;
prev->tcd->e_sg = 1;
- mdesc->tcd->start = 1;
+ /* only start explicitly on MDDRC channel */
+ if (cid == 32)
+ mdesc->tcd->start = 1;
prev = mdesc;
}
@@ -269,7 +274,15 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
if (first != prev)
mdma->tcd[cid].e_sg = 1;
- out_8(>regs->dmassrt, cid);
+
+ switch (cid) {
+ case 30:
+ out_8(>regs->dmaserq, cid);
+ break;
+ case 32:
+ out_8(>regs->dmassrt, cid);
+ break;
+ }
}
/* Handle interrupt on one half of DMA controller (32 channels) */
@@ -642,6 +655,136 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t
dst, dma_addr_t src,
return >desc;
}
+static struct dma_async_tx_descriptor *mpc_dma_prep_slave_sg(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction direction,
+ unsigned long flags, void *context)
+{
+ struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
+ struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
+ struct mpc_dma_desc *mdesc = NULL;
+ struct mpc_dma_tcd *tcd;
+ unsigned long flags;
+ struct scatterlist *sg;
+ dma_addr_t dst, src;
+ size_t len;
+ int iter, i;
+
+ if (!list_empty(>active))
+ return NULL;
+
+ for_each_sg(sgl, sg, sg_len, i) {
+ spin_lock_irqsave(>lock, flags);
+
+ mdesc = list_first_entry(>free, struct mpc_dma_desc,
+node);
+ if (!mdesc) {
+ spin_unlock_irqrestore(>lock, flags);
+ /* try to free completed descriptors */
+ mpc_dma_process_completed(mdma);
+ return NULL;
+ }
+
+ list_del(>node);
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ mdesc->error = 0;
+ tcd = mdesc->tcd;
+
+ /* Prepare Transfer Control Descriptor for this transaction */
+ memset(tcd, 0, sizeof(struct mpc_dma_tcd));
+
+ if (direction == DMA_DEV_TO_MEM) {
+ dst = sg_dma_address(sg);
+ src = mchan->per_paddr;
+ } else if (direction == DMA_MEM_TO_DEV) {
+ dst = mchan->per_paddr;
+ src = sg_dma_address(sg);
+ } else {
+ return NULL;
+ }
+
+ len = sg_dma_len(sg);
+
+ if (direction == DMA_MEM_TO_DEV) {
+ tcd->saddr = sg_dma_address(sg);
+ tcd->daddr = mchan->per_paddr;
+ tcd->soff = 4;
+ tcd->doff = 0;
+ } else {
+ tcd->saddr = mchan->per_paddr;
+ tcd->daddr = sg_dma_address(sg);
+ tcd->soff = 0;
+ tcd->doff = 4;
+ }
+
+ tcd->ssize = MPC_DMA_TSIZE_4;
+ tcd->dsize = MPC_DMA_TSIZE_4;
+ tcd->nbytes = 64;
+
+ iter = sg_dma_len(sg) / 64;
+
+ /* citer_linkch contains the high bits of iter */
+ tcd->citer_linkch = iter >> 9;
+ tcd->biter_linkch = iter >> 9;
+ tcd->citer = iter & 0x1ff;
+ tcd->biter = iter & 0x1ff;
+
+ tcd->e_sg = 0;
+
+ if (i != (sg_len - 1)) {
+ struct scatterlist *s = sg_next(sg);
+
+ if (!s)
+ tcd->dlast_sga = sg_dma_address(s);
+ tcd->e_sg = 1;
+ } else {
+ tcd->d_req = 1;
+ }
+ }
[PATCH 1/2] dmaengine: mpc512x_dma: use generic DMA DT bindings
Add generic DMA bindings and register the DMA controller
to DT DMA helpers.
Signed-off-by: Anatolij Gustschin
---
arch/powerpc/boot/dts/mpc5121.dtsi |5 ++-
drivers/dma/mpc512x_dma.c | 63 ++--
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi
b/arch/powerpc/boot/dts/mpc5121.dtsi
index 723e292..d1fe070 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -384,10 +384,13 @@
interrupts = <40 0x8>;
};
- dma@14000 {
+ dma0: dma@14000 {
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ #dma-channels = <64>;
+ #dma-requests = <64>;
};
};
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2d95673..bc6c356 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -641,6 +642,44 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst,
dma_addr_t src,
return >desc;
}
+struct mpc_dma_filter_args {
+ struct mpc_dma *mdma;
+ unsigned int chan_id;
+};
+
+static bool mpc_dma_filter(struct dma_chan *chan, void *param)
+{
+ struct mpc_dma_filter_args *fargs = param;
+
+ if (chan->device != >mdma->dma)
+ return false;
+
+ return (chan->chan_id == fargs->chan_id);
+}
+
+static struct dma_chan *mpc_dma_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count = dma_spec->args_count;
+ struct mpc_dma *mdma = ofdma->of_dma_data;
+ struct mpc_dma_filter_args fargs;
+ dma_cap_mask_t cap;
+
+ if (!mdma)
+ return NULL;
+
+ if (count != 1)
+ return NULL;
+
+ fargs.mdma = mdma;
+ fargs.chan_id = dma_spec->args[0];
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ return dma_request_channel(cap, mpc_dma_filter, );
+}
+
static int mpc_dma_probe(struct platform_device *op)
{
struct device_node *dn = op->dev.of_node;
@@ -791,11 +830,26 @@ static int mpc_dma_probe(struct platform_device *op)
/* Register DMA engine */
dev_set_drvdata(dev, mdma);
retval = dma_async_device_register(dma);
- if (retval) {
- devm_free_irq(dev, mdma->irq, mdma);
- irq_dispose_mapping(mdma->irq);
+ if (retval)
+ goto reg_err;
+
+ if (dev->of_node) {
+ retval = of_dma_controller_register(dev->of_node,
+ mpc_dma_xlate, mdma);
+ if (retval) {
+ dev_err(>dev,
+ "could not register of_dma_controller\n");
+ goto of_err;
+ }
}
+ return 0;
+
+of_err:
+ dma_async_device_unregister(>dma);
+reg_err:
+ devm_free_irq(dev, mdma->irq, mdma);
+ irq_dispose_mapping(mdma->irq);
return retval;
}
@@ -804,6 +858,9 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = >dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
+ if (dev->of_node)
+ of_dma_controller_free(dev->of_node);
+
dma_async_device_unregister(>dma);
devm_free_irq(dev, mdma->irq, mdma);
irq_dispose_mapping(mdma->irq);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: pxa: Use driver_data field to store pwm_nr
The driver_data field was used to store information about PWM_ID_BASE and
HAS_SECONDARY_PWM. PWM_ID_BASE is not used now after convert to pwm framework.
This patch stores the pwm_nr in driver_data field to simplify the code.
Signed-off-by: Axel Lin
---
drivers/pwm/pwm-pxa.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index b789882..019a8e0 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -22,13 +22,10 @@
#include
-#define HAS_SECONDARY_PWM 0x10
-#define PWM_ID_BASE(d) ((d) & 0xf)
-
static const struct platform_device_id pwm_id_table[] = {
- /* PWMhas_secondary_pwm? */
- { "pxa25x-pwm", 0 },
- { "pxa27x-pwm", 0 | HAS_SECONDARY_PWM },
+ /* PWMpwm_nr */
+ { "pxa25x-pwm", 1 },
+ { "pxa27x-pwm", 2 },
{ "pxa168-pwm", 1 },
{ "pxa910-pwm", 1 },
{ },
@@ -145,7 +142,7 @@ static int pwm_probe(struct platform_device *pdev)
pwm->chip.dev = >dev;
pwm->chip.ops = _pwm_ops;
pwm->chip.base = -1;
- pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
+ pwm->chip.npwm = id->driver_data;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
--
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] [TRIVIAL] Remove obsolete, iSeries specific, Makefile lines
On Fri, 29 Mar 2013, Paul Bolle wrote:
> Signed-off-by: Paul Bolle
> ---
> 0) Entirely untested.
>
> 1) See commit 3d066d77cf464ea1e47808f95243301fd2175a7f ("powerpc: remove
> CONFIG_PPC_ISERIES from the architecture Kconfig files") and commit
> ba7a4822b48fbc7afd6b567c18e316a03f46684d ("powerpc: Remove some of the
> legacy iSeries specific device drivers").
I believe you could remove all the corresponding major number defines from
include/uapi/linux/major.h while you are at it.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/2] watchdog: fix w83627hf_wdt reboot due to timeout expired
How about this? - t &= ~0xC0; /* disable keyboard & mouse turning off - watchdog */ + t &= ~0xE0; /* clear timeout occurred and disable keyboard +& mouse turning off watchdog */ Thanks, @Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: twl: Return proper error if twl6030_pwm_enable() fails
Return proper error instead of 0 if twl6030_pwm_enable() fails. Signed-off-by: Axel Lin --- drivers/pwm/pwm-twl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c index ee7fa5d..2782001 100644 --- a/drivers/pwm/pwm-twl.c +++ b/drivers/pwm/pwm-twl.c @@ -248,7 +248,7 @@ static int twl6030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm) twl->twl6030_toggle3 = val; out: mutex_unlock(>mutex); - return 0; + return ret; } static void twl6030_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] pwm: pxa: Remove clk_enabled field from struct pxa_pwm_chip
clk_enable/clk_disable maintain an enable_count, clk_prepare and clk_unprepare
also maintain a prepare_count. These APIs will do prepare/enable when the first
user calling these APIs, and do disable/unprepare when the corresponding counter
reach 0. Thus We don't need to maintain a clk_enabled counter here.
Signed-off-by: Axel Lin
---
drivers/pwm/pwm-pxa.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index 20370e6..b789882 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -48,7 +48,6 @@ struct pxa_pwm_chip {
struct device *dev;
struct clk *clk;
- int clk_enabled;
void __iomem*mmio_base;
};
@@ -108,24 +107,15 @@ static int pxa_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
static int pxa_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct pxa_pwm_chip *pc = to_pxa_pwm_chip(chip);
- int rc = 0;
- if (!pc->clk_enabled) {
- rc = clk_prepare_enable(pc->clk);
- if (!rc)
- pc->clk_enabled++;
- }
- return rc;
+ return clk_prepare_enable(pc->clk);
}
static void pxa_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct pxa_pwm_chip *pc = to_pxa_pwm_chip(chip);
- if (pc->clk_enabled) {
- clk_disable_unprepare(pc->clk);
- pc->clk_enabled--;
- }
+ clk_disable_unprepare(pc->clk);
}
static struct pwm_ops pxa_pwm_ops = {
@@ -152,8 +142,6 @@ static int pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm->clk))
return PTR_ERR(pwm->clk);
- pwm->clk_enabled = 0;
-
pwm->chip.dev = >dev;
pwm->chip.ops = _pwm_ops;
pwm->chip.base = -1;
--
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 1/1] TTY Fix NULL pointer error in tty_wakeup
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Sun, Mar 31, 2013 at 04:09:05PM +0800, frankie lin wrote: > Hi, greg, it's excited to get your reply. > In our case, it is gs_start_io(struct gs_port *port) in the file u_serial.c > who > call the tty_wakeup. We are trying to find the root cause. Something is wrong > before calling tty_wakeup, nevertheless it is reasonable to check the > parameter > first before test_bit. No, please find the root problem here in your driver. > To some extent, this patch can improve the robustness of function tty_wakeup, > isn't it? Not at the expense of papering over other bugs, sorry. 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/
