Re: [PATCH 05/19] sched: warnings in kernel/sched/fair.c
On Fri, Jan 25, 2013 at 6:14 AM, Arnd Bergmann wrote:
> a4c96ae319 "sched: Unthrottle rt runqueues in __disable_runtime()"
> turned the unthrottle_offline_cfs_rqs function into a static symbol,
> which now triggers a warning about it being potentially unused:
>
> kernel/sched/fair.c:2055:13: warning: 'unthrottle_offline_cfs_rqs' defined
> but not used [-Wunused-function]
>
> Marking it __maybe_unused shuts up the gcc warning and lets the
> compiler safely drop the function body when it's not being used.
>
> To reproduce, build the ARM bcm2835_defconfig.
>
> Signed-off-by: Arnd Bergmann
> Cc: Peter Boonstoppel
> Cc: Peter Zijlstra
> Cc: Paul Turner
> Cc: Ingo Molnar
> ---
> kernel/sched/fair.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 5eea870..81fa536 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2663,7 +2663,7 @@ static void destroy_cfs_bandwidth(struct cfs_bandwidth
> *cfs_b)
> hrtimer_cancel(_b->slack_timer);
> }
>
> -static void unthrottle_offline_cfs_rqs(struct rq *rq)
> +static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
Looks good.
Reviewed-by: Paul Turner
> {
> struct cfs_rq *cfs_rq;
>
> --
> 1.8.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RESEND RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task
On 01/25/2013 04:35 PM, Andrew Jones wrote:
On Fri, Jan 25, 2013 at 04:10:25PM +0530, Raghavendra K T wrote:
* Ingo Molnar [2013-01-24 11:32:13]:
* Raghavendra K T wrote:
From: Peter Zijlstra
In case of undercomitted scenarios, especially in large guests
yield_to overhead is significantly high. when run queue length of
source and target is one, take an opportunity to bail out and return
-ESRCH. This return condition can be further exploited to quickly come
out of PLE handler.
(History: Raghavendra initially worked on break out of kvm ple handler upon
seeing source runqueue length = 1, but it had to export rq length).
Peter came up with the elegant idea of return -ESRCH in scheduler core.
Signed-off-by: Peter Zijlstra
Raghavendra, Checking the rq length of target vcpu condition added.(thanks Avi)
Reviewed-by: Srikar Dronamraju
Signed-off-by: Raghavendra K T
Acked-by: Andrew Jones
Tested-by: Chegu Vinod
---
kernel/sched/core.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..fc219a5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4289,7 +4289,10 @@ EXPORT_SYMBOL(yield);
* It's the caller's job to ensure that the target task struct
* can't go away on us before we can do any checks.
*
- * Returns true if we indeed boosted the target task.
+ * Returns:
+ * true (>0) if we indeed boosted the target task.
+ * false (0) if we failed to boost the target.
+ * -ESRCH if there's no task to yield to.
*/
bool __sched yield_to(struct task_struct *p, bool preempt)
{
@@ -4303,6 +4306,15 @@ bool __sched yield_to(struct task_struct *p, bool
preempt)
again:
p_rq = task_rq(p);
+ /*
+* If we're the only runnable task on the rq and target rq also
+* has only one task, there's absolutely no point in yielding.
+*/
+ if (rq->nr_running == 1 && p_rq->nr_running == 1) {
+ yielded = -ESRCH;
+ goto out_irq;
+ }
Looks good to me in principle.
Would be nice to get more consistent benchmark numbers. Once
those are unambiguously showing that this is a win:
Acked-by: Ingo Molnar
I ran the test with kernbench and sysbench again on 32 core mx3850
machine with 32 vcpu guests. Results shows definite improvements.
ebizzy and dbench show similar improvement for 1x overcommit
(note that stdev for 1x in dbench is lesser improvemet is now seen at
only 20%)
[ all the experiments are taken out of 8 run averages ].
The patches benefit large guest undercommit scenarios, so I believe
with large guest performance improvemnt is even significant. [ Chegu
Vinod results show performance near to no ple cases ].
The last results you posted for dbench for the patched 1x case were
showing much better throughput than the no-ple 1x case, which is what
was strange. Is that still happening? You don't have the no-ple 1x
data here this time. The percent errors look a lot better.
I re-ran the experiment and almost got 4% (13500 vs 14100) less
throughput compared to patched for no-ple case. ( I believe this
variation may be due to having 4 guest with 3 idle.. as no-ple is very
sensitive after 1x).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND V5 4/6] perf, x86: Move MSR address offset calculation to architecture specific files
On Fri, Jan 25, 2013 at 12:15:37PM +0100, Stephane Eranian wrote:
> On Thu, Jan 10, 2013 at 8:50 PM, Jacob Shin wrote:
> > Move counter index to MSR address offset calculation to architecture
> > specific files. This prepares the way for perf_event_amd to enable
> > counter addresses that are not contiguous -- for example AMD Family
> > 15h processors have 6 core performance counters starting at 0xc0010200
> > and 4 northbridge performance counters starting at 0xc0010240.
> >
> > Signed-off-by: Jacob Shin
> > ---
> > arch/x86/kernel/cpu/perf_event.h | 21 -
> > arch/x86/kernel/cpu/perf_event_amd.c | 42
> > ++
> > 2 files changed, 47 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/perf_event.h
> > b/arch/x86/kernel/cpu/perf_event.h
> > index 115c1ea..4440218 100644
> > --- a/arch/x86/kernel/cpu/perf_event.h
> > +++ b/arch/x86/kernel/cpu/perf_event.h
> > @@ -325,6 +325,7 @@ struct x86_pmu {
> > int (*schedule_events)(struct cpu_hw_events *cpuc, int
> > n, int *assign);
> > unsignedeventsel;
> > unsignedperfctr;
> > + int (*addr_offset)(int index, int eventsel);
> > u64 (*event_map)(int);
> > int max_events;
> > int num_counters;
> > @@ -446,28 +447,16 @@ extern u64 __read_mostly hw_cache_extra_regs
> >
> > u64 x86_perf_event_update(struct perf_event *event);
> >
> > -static inline int x86_pmu_addr_offset(int index)
> > -{
> > - int offset;
> > -
> > - /* offset = X86_FEATURE_PERFCTR_CORE ? index << 1 : index */
> > - alternative_io(ASM_NOP2,
> > - "shll $1, %%eax",
> > - X86_FEATURE_PERFCTR_CORE,
> > - "=a" (offset),
> > - "a" (index));
> > -
> > - return offset;
> > -}
> > -
> > static inline unsigned int x86_pmu_config_addr(int index)
> > {
> > - return x86_pmu.eventsel + x86_pmu_addr_offset(index);
> > + return x86_pmu.eventsel +
> > + (x86_pmu.addr_offset ? x86_pmu.addr_offset(index, 1) :
> > index);
> > }
> >
> > static inline unsigned int x86_pmu_event_addr(int index)
> > {
> > - return x86_pmu.perfctr + x86_pmu_addr_offset(index);
> > + return x86_pmu.perfctr +
> > + (x86_pmu.addr_offset ? x86_pmu.addr_offset(index, 0) :
> > index);
> > }
> Would be better to use a constant name instead of 1 and 0 to name a event_sel
> vs. a counter. It would help the reader understand what this is about
> as that may
> be useful for other processors as well.
Yes will do .. or should I use bool instead? Which would be preferred?
>
> > int x86_setup_perfctr(struct perf_event *event);
> > diff --git a/arch/x86/kernel/cpu/perf_event_amd.c
> > b/arch/x86/kernel/cpu/perf_event_amd.c
> > index 0c2cc51..ef1df38 100644
> > --- a/arch/x86/kernel/cpu/perf_event_amd.c
> > +++ b/arch/x86/kernel/cpu/perf_event_amd.c
> > @@ -132,6 +132,47 @@ static u64 amd_pmu_event_map(int hw_event)
> > return amd_perfmon_event_map[hw_event];
> > }
> >
> > +/*
> > + * Previously calculated offsets
> > + */
> > +static unsigned int event_offsets[X86_PMC_IDX_MAX] __read_mostly;
> > +static unsigned int count_offsets[X86_PMC_IDX_MAX] __read_mostly;
> > +
> > +/*
> > + * Legacy CPUs:
> > + * 4 counters starting at 0xc001 each offset by 1
> > + *
> > + * CPUs with core performance counter extensions:
> > + * 6 counters starting at 0xc0010200 each offset by 2
> > + */
> > +static inline int amd_pmu_addr_offset(int index, int eventsel)
> > +{
> > + int offset;
> > +
> > + if (!index)
> > + return index;
> > +
> > + if (eventsel)
> > + offset = event_offsets[index];
> > + else
> > + offset = count_offsets[index];
> > +
> > + if (offset)
> > + return offset;
> > +
> > + if (!cpu_has_perfctr_core)
> > + offset = index;
> > + else
> > + offset = index << 1;
> > +
> > + if (eventsel)
> > + event_offsets[index] = offset;
> > + else
> > + count_offsets[index] = offset;
> > +
> > + return offset;
> > +}
> > +
> > static int amd_pmu_hw_config(struct perf_event *event)
> > {
> > int ret;
> > @@ -578,6 +619,7 @@ static __initconst const struct x86_pmu amd_pmu = {
> > .schedule_events= x86_schedule_events,
> > .eventsel = MSR_K7_EVNTSEL0,
> > .perfctr= MSR_K7_PERFCTR0,
> > + .addr_offset= amd_pmu_addr_offset,
> > .event_map = amd_pmu_event_map,
> > .max_events = ARRAY_SIZE(amd_perfmon_event_map),
> > .num_counters = AMD64_NUM_COUNTERS,
> > --
> > 1.7.9.5
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Re: [PATCH V3 RESEND RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task
On 01/25/2013 04:17 PM, Ingo Molnar wrote:
* Raghavendra K T wrote:
* Ingo Molnar [2013-01-24 11:32:13]:
* Raghavendra K T wrote:
From: Peter Zijlstra
In case of undercomitted scenarios, especially in large guests
yield_to overhead is significantly high. when run queue length of
source and target is one, take an opportunity to bail out and return
-ESRCH. This return condition can be further exploited to quickly come
out of PLE handler.
(History: Raghavendra initially worked on break out of kvm ple handler upon
seeing source runqueue length = 1, but it had to export rq length).
Peter came up with the elegant idea of return -ESRCH in scheduler core.
Signed-off-by: Peter Zijlstra
Raghavendra, Checking the rq length of target vcpu condition added.(thanks Avi)
Reviewed-by: Srikar Dronamraju
Signed-off-by: Raghavendra K T
Acked-by: Andrew Jones
Tested-by: Chegu Vinod
---
kernel/sched/core.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..fc219a5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4289,7 +4289,10 @@ EXPORT_SYMBOL(yield);
* It's the caller's job to ensure that the target task struct
* can't go away on us before we can do any checks.
*
- * Returns true if we indeed boosted the target task.
+ * Returns:
+ * true (>0) if we indeed boosted the target task.
+ * false (0) if we failed to boost the target.
+ * -ESRCH if there's no task to yield to.
*/
bool __sched yield_to(struct task_struct *p, bool preempt)
{
@@ -4303,6 +4306,15 @@ bool __sched yield_to(struct task_struct *p, bool
preempt)
again:
p_rq = task_rq(p);
+ /*
+* If we're the only runnable task on the rq and target rq also
+* has only one task, there's absolutely no point in yielding.
+*/
+ if (rq->nr_running == 1 && p_rq->nr_running == 1) {
+ yielded = -ESRCH;
+ goto out_irq;
+ }
Looks good to me in principle.
Would be nice to get more consistent benchmark numbers. Once
those are unambiguously showing that this is a win:
Acked-by: Ingo Molnar
I ran the test with kernbench and sysbench again on 32 core mx3850
machine with 32 vcpu guests. Results shows definite improvements.
ebizzy and dbench show similar improvement for 1x overcommit
(note that stdev for 1x in dbench is lesser improvemet is now seen at
only 20%)
[ all the experiments are taken out of 8 run averages ].
The patches benefit large guest undercommit scenarios, so I believe
with large guest performance improvemnt is even significant. [ Chegu
Vinod results show performance near to no ple cases ]. Unfortunately I
do not have a machine to test larger guest (>32).
Ingo, Please let me know if this is okay to you.
base kernel = 3.8.0-rc4
+---+---+---++---+
kernbench (time in sec lower is better)
+---+---+---++---+
basestdevpatchedstdev %improve
+---+---+---++---+
1x 46.6028 1.8672 42.4494 1.1390 8.91234
2x 99.9074 9.1859 90.4050 2.6131 9.51121
+---+---+---++---+
+---+---+---++---+
sysbench (time in sec lower is better)
+---+---+---++---+
basestdevpatchedstdev %improve
+---+---+---++---+
1x 18.7402 0.3764 17.7431 0.3589 5.32065
2x 13.2238 0.1935 13.0096 0.3152 1.61981
+---+---+---++---+
+---+---+---++---+
ebizzy (records/sec higher is better)
+---+---+---++---+
basestdevpatchedstdev %improve
+---+---+---++---+
1x 2421.900019.1801 5883.1000 112.7243 142.91259
+---+---+---++---+
+---+---+---++---+
dbench (throughput MB/sec higher is better)
+---+---+---++---+
basestdevpatchedstdev %improve
+---+---+---++---+
1x 11675.9900 857.415414103.5000 215.842520.79061
+---+---+---++---+
The numbers look pretty convincing, thanks. The workloads were
CPU bound most of the time, right?
Yes. CPU bound most of the time. I also used tmpfs to reduce io
overhead (for dbbench).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: [PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263
On Friday 25 January 2013 16:42:19 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:14 Fri 25 Jan , Arnd Bergmann wrote:
> > For the past three years, we have had a #warning in
> > mach-at91 about the sdram_selfrefresh_enable or
> > at91sam9_standby functions possibly not working on
> > at91sam9263. In the meantime a function was added
> > to do the right thing on at91sam9g45, which looks like
> > it should also work on '9263.
> >
> > This patch blindly removes the warning and changes the
> > at91sam9263 to use the same code at at91sam9g45, which
> > may or may not be the right solution. If it is not,
> > maybe someone could provide a better fix.
> it's not
>
> the 9g45 use DDR Controler where the 9263 use a SDRAM controler
>
Ah, right. What about this one then?
Arnd
8<-
Subject: [PATCH] ARM: at91: suspend both memory controllers on at91sam9263
For the past three years, we have had a #warning in
mach-at91 about the sdram_selfrefresh_enable or
at91sam9_standby functions possibly not working on
at91sam9263. In the meantime a function was added
to do the right thing on at91sam9g45, which looks like
it should also work on '9263.
This patch blindly removes the warning and changes the
at91sam9263 to use the same code at at91sam9g45, which
may or may not be the right solution. If it is not,
maybe someone could provide a better fix.
Signed-off-by: Arnd Bergmann
Cc: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard
Cc: Andrew Victor
Cc: Albin Tonnerre
Cc: Daniel Lezcano
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..4c67946 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
at91rm9200_standby();
else if (cpu_is_at91sam9g45())
at91sam9g45_standby();
+ else if (cpu_is_at91sam9263())
+ at91sam9263_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..b8017c1 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
at91rm9200_standby();
else if (cpu_is_at91sam9g45())
at91sam9g45_standby();
+ else if (cpu_is_at91sam9263())
+ at91sam9263_standby();
else
at91sam9_standby();
break;
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..2f5908f 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
}
-#ifdef CONFIG_SOC_AT91SAM9263
-/*
- * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
- * handle those cases both here and in the Suspend-To-RAM support.
+/* We manage both DDRAM/SDRAM controllers, we need more than one value to
+ * remember.
*/
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
+static inline void at91sam9263_standby(void)
+{
+ u32 lpr0, lpr1;
+ u32 saved_lpr0, saved_lpr1;
+
+ saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
+ lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
+ lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+ saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
+ lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
+ lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+ /* self-refresh mode now */
+ at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
+ at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
+
+ cpu_do_idle();
+
+ at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
+ at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
+}
static inline void at91sam9_standby(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 1/9] staging: zsmalloc: add gfp flags to zs_create_pool
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: Re: [PATCHv2 1/9] staging: zsmalloc: add gfp flags to zs_create_pool > > On 01/24/2013 07:33 PM, Minchan Kim wrote: > > Hi Seth, frontswap guys > > > > On Tue, Jan 8, 2013 at 5:24 AM, Seth Jennings > > wrote: > >> zs_create_pool() currently takes a gfp flags argument > >> that is used when growing the memory pool. However > >> it is not used in allocating the metadata for the pool > >> itself. That is currently hardcoded to GFP_KERNEL. > >> > >> zswap calls zs_create_pool() at swapon time which is done > >> in atomic context, resulting in a "might sleep" warning. > > > > I didn't review this all series, really sorry but totday I saw Nitin > > added Acked-by so I'm afraid Greg might get it under my radar. I'm not > > strong against but I would like know why we should call frontswap_init > > under swap_lock? Is there special reason? > > The call stack is: > > SYSCALL_DEFINE2(swapon.. <-- swapon_mutex taken here > enable_swap_info() <-- swap_lock taken here > frontswap_init() > __frontswap_init() > zswap_frontswap_init() > zs_create_pool() > > It isn't entirely clear to me why frontswap_init() is called under > lock. Then again, I'm not entirely sure what the swap_lock protects. > There are no comments near the swap_lock definition to tell me. > > I would guess that the intent is to block any writes to the swap > device until frontswap_init() has completed. > > Dan care to weigh in? I think frontswap's first appearance needs to be atomic, i.e. the transition from (a) frontswap is not present and will fail all calls, to (b) frontswap is fully functional... that transition must be atomic. And, once Konrad's module patches are in, the opposite transition must be atomic also. But there are most likely other ways to do those transitions atomically that don't need to hold swap_lock. Honestly, I never really focused on the initialization code so I am very open to improvements as long as they work for all the various frontswap backends. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND V5 2/6] perf, amd: Generalize northbridge constraints code for family 15h
On Fri, Jan 25, 2013 at 12:07:40PM +0100, Stephane Eranian wrote:
> On Thu, Jan 10, 2013 at 8:50 PM, Jacob Shin wrote:
> > From: Robert Richter
> >
> > Generalize northbridge constraints code for family 10h so that later
> > we can reuse the same code path with other AMD processor families that
> > have the same northbridge event constraints.
> >
> > Signed-off-by: Robert Richter
> > Signed-off-by: Jacob Shin
> > ---
> > arch/x86/kernel/cpu/perf_event_amd.c | 43
> > --
> > 1 file changed, 25 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/perf_event_amd.c
> > b/arch/x86/kernel/cpu/perf_event_amd.c
> > index e7963c7..9541fe5 100644
> > --- a/arch/x86/kernel/cpu/perf_event_amd.c
> > +++ b/arch/x86/kernel/cpu/perf_event_amd.c
> > @@ -188,20 +188,13 @@ static inline int amd_has_nb(struct cpu_hw_events
> > *cpuc)
> > return nb && nb->nb_id != -1;
> > }
> >
> > -static void amd_put_event_constraints(struct cpu_hw_events *cpuc,
> > - struct perf_event *event)
> > +static void __amd_put_nb_event_constraints(struct cpu_hw_events *cpuc,
> > + struct perf_event *event)
> > {
> > - struct hw_perf_event *hwc = >hw;
> > struct amd_nb *nb = cpuc->amd_nb;
> > int i;
> >
> > /*
> > -* only care about NB events
> > -*/
> > - if (!(amd_has_nb(cpuc) && amd_is_nb_event(hwc)))
> > - return;
> > -
> > - /*
> > * need to scan whole list because event may not have
> > * been assigned during scheduling
> > *
> > @@ -247,12 +240,13 @@ static void amd_put_event_constraints(struct
> > cpu_hw_events *cpuc,
> >*
> >* Given that resources are allocated (cmpxchg), they must be
> >* eventually freed for others to use. This is accomplished by
> > - * calling amd_put_event_constraints().
> > + * calling __amd_put_nb_event_constraints()
> >*
> >* Non NB events are not impacted by this restriction.
> >*/
> > static struct event_constraint *
> > -amd_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event
> > *event)
> > +__amd_get_nb_event_constraints(struct cpu_hw_events *cpuc, struct
> > perf_event *event,
> > + struct event_constraint *c)
> > {
> > struct hw_perf_event *hwc = >hw;
> > struct amd_nb *nb = cpuc->amd_nb;
> > @@ -260,12 +254,6 @@ amd_get_event_constraints(struct cpu_hw_events *cpuc,
> > struct perf_event *event)
> > int idx, new = -1;
> >
> > /*
> > -* if not NB event or no NB, then no constraints
> > -*/
> > - if (!(amd_has_nb(cpuc) && amd_is_nb_event(hwc)))
> > - return
> > -
> > - /*
> > * detect if already present, if so reuse
> > *
> > * cannot merge with actual allocation
> > @@ -275,7 +263,7 @@ amd_get_event_constraints(struct cpu_hw_events *cpuc,
> > struct perf_event *event)
> > * because of successive calls to x86_schedule_events() from
> > * hw_perf_group_sched_in() without hw_perf_enable()
> > */
> > - for (idx = 0; idx < x86_pmu.num_counters; idx++) {
> > + for_each_set_bit(idx, c->idxmsk, X86_PMC_IDX_MAX) {
>
> So here you're using X86_PMC_IDX_MAX but in
> __amd_put_nb_event_constraints() you're using
> x86_pmu.num_counters.
>
> There is implicit assumption in the AMD code the counters index
> namespace is contiguous. That
> means the uncore counters show up right after the core counters. On
> Fam15h, that would be NB
> counters start at index 6, on Fam10h at index 4. In that case, the
> constraint mask cannot have bits set
> beyond num_counters, so why not use that limit in
> amd_get_event_constraints()? It would significantly
> cut down on the number of iterations in the loop from 64 down to 10 on Fam15h.
Yes, you are right, I will change that in V6.
Thanks,
>
>
> > if (new == -1 || hwc->idx == idx)
> > /* assign free slot, prefer hwc->idx */
> > old = cmpxchg(nb->owners + idx, NULL, event);
> > @@ -391,6 +379,25 @@ static void amd_pmu_cpu_dead(int cpu)
> > }
> > }
> >
> > +static struct event_constraint *
> > +amd_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event
> > *event)
> > +{
> > + /*
> > +* if not NB event or no NB, then no constraints
> > +*/
> > + if (!(amd_has_nb(cpuc) && amd_is_nb_event(>hw)))
> > + return
> > +
> > + return __amd_get_nb_event_constraints(cpuc, event, );
> > +}
> > +
> > +static void amd_put_event_constraints(struct cpu_hw_events *cpuc,
> > + struct perf_event *event)
> > +{
> > + if (amd_has_nb(cpuc) && amd_is_nb_event(>hw))
> > + __amd_put_nb_event_constraints(cpuc, event);
> > +}
> > +
> > PMU_FORMAT_ATTR(event,
Re: [PATCH] fbcon: fix locking harder
On Fri, Jan 25, 2013 at 2:43 AM, Dave Airlie wrote:
> Okay so Alan's patch handled the case where there was no registered fbcon,
> however the other path entered in set_con2fb_map pit.
>
> In there we called fbcon_takeover, but we also took the console lock in a
> couple
> of places. So push the console lock out to the callers of set_con2fb_map,
>
> this means fbmem and switcheroo needed to take the lock around the fb notifier
> entry points that lead to this.
>
> This should fix the efifb regression seen by Maarten.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/vga/vga_switcheroo.c | 3 +++
> drivers/video/console/fbcon.c| 11 ---
> drivers/video/fbmem.c| 2 ++
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
[cut]
> ret = vgasr_priv.handler->switchto(new_client->id);
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 2aef9ca..2e2d959 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -842,6 +842,8 @@ static void con2fb_init_display(struct vc_data *vc,
> struct fb_info *info,
> *
> * Maps a virtual console @unit to a frame buffer device
> * @newidx.
> + *
> + * This should be called with the console lock held.
> */
> static int set_con2fb_map(int unit, int newidx, int user)
> {
What about throwing a WARN_CONSOLE_UNLOCKED(); in here to make sure
this new rule is obeyed?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/19] ARM: at91: suspend both memory controllers on at91sam9263
On 14:14 Fri 25 Jan , Arnd Bergmann wrote:
> For the past three years, we have had a #warning in
> mach-at91 about the sdram_selfrefresh_enable or
> at91sam9_standby functions possibly not working on
> at91sam9263. In the meantime a function was added
> to do the right thing on at91sam9g45, which looks like
> it should also work on '9263.
>
> This patch blindly removes the warning and changes the
> at91sam9263 to use the same code at at91sam9g45, which
> may or may not be the right solution. If it is not,
> maybe someone could provide a better fix.
it's not
the 9g45 use DDR Controler where the 9263 use a SDRAM controler
Best Regards,
J.
>
> Signed-off-by: Arnd Bergmann
> Cc: Nicolas Ferre
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Andrew Victor
> Cc: Albin Tonnerre
> Cc: Daniel Lezcano
> ---
> arch/arm/mach-at91/cpuidle.c | 2 +-
> arch/arm/mach-at91/pm.c | 2 +-
> arch/arm/mach-at91/pm.h | 8
> 3 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 0c63815..208d486 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -36,7 +36,7 @@ static int at91_enter_idle(struct cpuidle_device *dev,
> {
> if (cpu_is_at91rm9200())
> at91rm9200_standby();
> - else if (cpu_is_at91sam9g45())
> + else if (cpu_is_at91sam9g45() || cpu_is_at91sam9263())
> at91sam9g45_standby();
> else
> at91sam9_standby();
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index adb6db8..f6bd4fa 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -265,7 +265,7 @@ static int at91_pm_enter(suspend_state_t state)
>*/
> if (cpu_is_at91rm9200())
> at91rm9200_standby();
> - else if (cpu_is_at91sam9g45())
> + else if (cpu_is_at91sam9g45() || cpu_is_at91sam9263())
> at91sam9g45_standby();
> else
> at91sam9_standby();
> diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
> index 38f467c..5252216 100644
> --- a/arch/arm/mach-at91/pm.h
> +++ b/arch/arm/mach-at91/pm.h
> @@ -70,14 +70,6 @@ static inline void at91sam9g45_standby(void)
> at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
> }
>
> -#ifdef CONFIG_SOC_AT91SAM9263
> -/*
> - * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
> - * handle those cases both here and in the Suspend-To-RAM support.
> - */
> -#warning Assuming EB1 SDRAM controller is *NOT* used
> -#endif
> -
> static inline void at91sam9_standby(void)
> {
> u32 saved_lpr, lpr;
> --
> 1.8.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] block/partition/msdos: detect AIX formatted disks even without 55aa
AIX formatted disks do not always have the MSDOS 55aa signature.
This happens e.g. for unbootable AIX disks.
Up to now, such disks were not recognized as AIX disks, because of the
missing 55aa. Fix that by inverting the two tests. Let's first
check for the AIX magic strings, and only if that fails check for
the MSDOS magic word.
Signed-off-by: Philippe De Muyter
---
block/partitions/msdos.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
v2: add a comment to avoid accidental removal of the tests order
(suggested by Andreas Mohr )
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 8752a5d..7681cd2 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -455,14 +455,19 @@ int msdos_partition(struct parsed_partitions *state)
data = read_part_sector(state, 0, );
if (!data)
return -1;
- if (!msdos_magic_present(data + 510)) {
+
+ /*
+* Note order! (some AIX disks, e.g. unbootable kind,
+* have no MSDOS 55aa)
+*/
+ if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+ strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
- if (aix_magic_present(state, data)) {
+ if (!msdos_magic_present(data + 510)) {
put_dev_sector(sect);
- strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon2] [PATCH RESEND V5 0/6] perf, amd: Enable AMD family 15h northbridge counters
On Fri, Jan 25, 2013 at 10:42:57AM +0100, Stephane Eranian wrote:
> Hi Jacob,
>
> I will apply this patch to libpfm4.
> But I have a question. Why aren't the other uncore
> events included here as well? I am talking about
> the events listed in BKDG sections 3.16.2 to 3.16.6?
> Are those NOT supported by your kernel patchset?
Oh, you are right, they are supported. I'm not sure why I overlooked
them. I will send out a V2 that includes all of those events as well.
Sorry about that.
-Jacob
>
>
> On Thu, Jan 24, 2013 at 11:06 PM, Jacob Shin wrote:
> > On Thu, Jan 24, 2013 at 02:31:59PM +0100, Stephane Eranian wrote:
> >> On Thu, Jan 10, 2013 at 8:50 PM, Jacob Shin wrote:
> >> > The following patchset enables 4 additional performance counters in
> >> > AMD family 15h processors that count northbridge events -- such as
> >> > number of DRAM accesses.
> >> >
> >> In order for me to test this patch set more thoroughly it would help if you
> >> could also provide me a patch to add the Fam15h uncore events to libpfm4.
> >> In the past, Robert Richter took care of this. I hope you can fill his
> >> role for
> >> this. So please, if you could send me the patch quickly, that would help
> >> the review of your patch.
> >
> > Hi Stephane,
> >
> > Here is the corresponding libpfm4 patch. Thank you for taking the time
> > to review the patchset. I hope this helps .. If we can get AMD related
> > perf kernel side patchsets to upstream, I will be more than happy to
> > support AMD related libpfm4 efforts going forward.
> >
> > Thanks!
> >
> > >From 47d3267dfa24b9071c76f4a22bd059b0e4032002 Mon Sep 17 00:00:00 2001
> > From: Jacob Shin
> > Date: Thu, 24 Jan 2013 15:37:37 -0600
> > Subject: [PATCH 1/1] Add AMD Family 15h northbridge performance events
> >
> > libpfm4 side support for the following Linux kernel patchset:
> > http://lkml.org/lkml/2013/1/10/450
> >
> > Reference -- BIOS and Kernel Developer Guide (BKDG) for AMD Family 15h
> > Models 00h-0Fh Processors:
> >
> > http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
> >
> > Signed-off-by: Jacob Shin
> > ---
> > lib/events/amd64_events_fam15h.h | 155
> > ++
> > 1 file changed, 155 insertions(+)
> >
> > diff --git a/lib/events/amd64_events_fam15h.h
> > b/lib/events/amd64_events_fam15h.h
> > index 7f654e8..0276782 100644
> > --- a/lib/events/amd64_events_fam15h.h
> > +++ b/lib/events/amd64_events_fam15h.h
> > @@ -752,6 +752,126 @@ static const amd64_umask_t
> > amd64_fam15h_l2_prefetcher_trigger_events[]={
> > },
> > };
> >
> > +static const amd64_umask_t amd64_fam15h_dram_accesses[]={
> > + { .uname = "DCT0_PAGE_HIT",
> > + .udesc = "DCT0 Page hit",
> > + .ucode = 0x1,
> > + },
> > + { .uname = "DCT0_PAGE_MISS",
> > + .udesc = "DCT0 Page Miss",
> > + .ucode = 0x2,
> > + },
> > + { .uname = "DCT0_PAGE_CONFLICT",
> > + .udesc = "DCT0 Page Conflict",
> > + .ucode = 0x4,
> > + },
> > + { .uname = "DCT1_PAGE_HIT",
> > + .udesc = "DCT1 Page hit",
> > + .ucode = 0x8,
> > + },
> > + { .uname = "DCT1_PAGE_MISS",
> > + .udesc = "DCT1 Page Miss",
> > + .ucode = 0x10,
> > + },
> > + { .uname = "DCT1_PAGE_CONFLICT",
> > + .udesc = "DCT1 Page Conflict",
> > + .ucode = 0x20,
> > + },
> > + { .uname = "ALL",
> > + .udesc = "All sub-events selected",
> > + .ucode = 0x3f,
> > + .uflags = AMD64_FL_NCOMBO | AMD64_FL_DFL,
> > + },
> > +};
> > +
> > +static const amd64_umask_t
> > amd64_fam15h_dram_controller_page_table_overflows[]={
> > + { .uname = "DCT0_PAGE_TABLE_OVERFLOW",
> > + .udesc = "DCT0 Page Table Overflow",
> > + .ucode = 0x1,
> > + },
> > + { .uname = "DCT1_PAGE_TABLE_OVERFLOW",
> > + .udesc = "DCT1 Page Table Overflow",
> > + .ucode = 0x2,
> > + },
> > + { .uname = "ALL",
> > + .udesc = "All sub-events selected",
> > + .ucode = 0x3,
> > + .uflags = AMD64_FL_NCOMBO | AMD64_FL_DFL,
> > + },
> > +};
> > +
> > +static const amd64_umask_t
> > amd64_fam15h_memory_controller_dram_command_slots_missed[]={
> > + { .uname = "DCT0_COMMAND_SLOTS_MISSED",
> > + .udesc = "DCT0 Command Slots Missed (in MemClks)",
> > + .ucode = 0x1,
> > + },
> > + { .uname = "DCT1_COMMAND_SLOTS_MISSED",
> > + .udesc = "DCT1 Command Slots Missed (in MemClks)",
> > + .ucode = 0x2,
> > + },
> > + { .uname = "ALL",
> > + .udesc = "All sub-events selected",
> > + .ucode = 0x3,
> > + .uflags = AMD64_FL_NCOMBO | AMD64_FL_DFL,
> > + },
> > +};
> > +
> > +static const amd64_umask_t amd64_fam15h_memory_controller_turnarounds[]={
> > + { .uname = "DCT0_DIMM_TURNAROUND",
> > + .udesc = "DCT0 DIMM (chip select) turnaround",
> > + .ucode = 0x1,
> > + },
> > + { .uname = "DCT0_READ_TO_WRITE_TURNAROUND",
> > + .udesc = "DCT0 Read to write turnaround",
> > + .ucode = 0x2,
> > + },
> > + { .uname = "DCT0_WRITE_TO_READ_TURNAROUND",
> > +
Re: [PATCH] block/partition/msdos: detect AIX formatted disks even without 55aa
Hi,
IMHO that patch would better have a small but important one-liner comment
(one cannot rely on people always making use of SCM history functionality,
thereby this would be at risk of getting reversed accidentally eventually).
E.g.
/* Note order! (some AIX disks, e.g. unbootable kind, have no MSDOS 55aa) */
if (aix_magic_present(state, data)) {
.
.
.
Apart from that: nice compat catch!
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tracepoint] cargo-culting considered harmful...
On Fri, Jan 25, 2013 at 09:49:53AM -0500, Mathieu Desnoyers wrote:
> static
> void lttng_enumerate_task_fd(struct lttng_session *session,
> struct task_struct *p, char *tmp)
> {
> struct fdtable *fdt;
> struct file *filp;
> unsigned int i;
> const unsigned char *path;
>
> task_lock(p);
> if (!p->files)
> goto unlock_task;
> spin_lock(>files->file_lock);
> fdt = files_fdtable(p->files);
> for (i = 0; i < fdt->max_fds; i++) {
> filp = fcheck_files(p->files, i);
> if (!filp)
> continue;
> path = d_path(>f_path, tmp, PAGE_SIZE);
> /* Make sure we give at least some info */
> trace_lttng_statedump_file_descriptor(session, p, i,
> IS_ERR(path) ?
> filp->f_dentry->d_name.name :
> path);
> }
> spin_unlock(>files->file_lock);
> unlock_task:
> task_unlock(p);
> }
*cringe*
a) yes, it needs d_lock for that ->d_name access
b) iterate_fd() is there for purpose; use it, instead of open-coding the
damn loop. Something like
struct ctx {
char *page;
struct lttng_session *session,
struct task_struct *p;
};
static int dump_one(void *p, struct file *file, unsigned fd)
{
struct ctx *ctx = p;
const char *s = d_path(>f_path, ctx->page, PAGE_SIZE);
struct dentry *dentry;
if (!IS_ERR(s)) {
trace_lttng_statedump_file_descriptor(ctx->session, ctx->p, fd,
s);
return 0;
}
/* Make sure we give at least some info */
dentry = file->f_path.dentry;
spin_lock(>d_lock);
trace_lttng_statedump_file_descriptor(ctx->session, ctx->p, fd,
dentry->d_name);
spin_unlock(>d_lock);
return 0;
}
...
task_lock(p);
iterate_fd(p->files, 0, dump_one, &(struct ctx){tmp, session, p});
task_unlock(p);
assuming it wouldn't be better to pass tmp/session/p as the single pointer
to struct in the first place - I don't know enough about the callers of
that sucker to tell. And yes, iterate_fd() will DTRT if given NULL as the
first argument. The second argument is "which descriptor should I start
from?", callback is called for everything present in the table starting from
that place until it returns non-zero or the end of table is reached...
PS: people really ought to be forced to read their code aloud over the phone -
that would rapidly improve the choice of identifiers ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/18] perf: add generic memory sampling interface
On Fri, Jan 25, 2013 at 10:01 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> This patch adds PERF_SAMPLE_DSRC.
>>
>> PERF_SAMPLE_DSRC collects the data source, i.e., where
>> did the data associated with the sampled instruction
>> come from. Information is stored in a perf_mem_dsrc
>> structure. It contains opcode, mem level, tlb, snoop,
>> lock information, subject to availability in hardware.
>>
>> Signed-off-by: Stephane Eranian
>> ---
>> include/linux/perf_event.h |2 ++
>> include/uapi/linux/perf_event.h | 68
>> +--
>> kernel/events/core.c|6
>> 3 files changed, 74 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index bb2429d..8fe4610 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -579,6 +579,7 @@ struct perf_sample_data {
>> u32 reserved;
>> } cpu_entry;
>> u64 period;
>> + union perf_mem_dsrcdsrc;
>> struct perf_callchain_entry *callchain;
>> struct perf_raw_record *raw;
>> struct perf_branch_stack*br_stack;
>> @@ -599,6 +600,7 @@ static inline void perf_sample_data_init(struct
>> perf_sample_data *data,
>> data->regs_user.regs = NULL;
>> data->stack_user_size = 0;
>> data->weight = 0;
>> + data->dsrc.val = 0;
>> }
>>
>> extern void perf_output_sample(struct perf_output_handle *handle,
>> diff --git a/include/uapi/linux/perf_event.h
>> b/include/uapi/linux/perf_event.h
>> index 3e6c394..3e4844c 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -133,9 +133,9 @@ enum perf_event_sample_format {
>> PERF_SAMPLE_REGS_USER = 1U << 12,
>> PERF_SAMPLE_STACK_USER = 1U << 13,
>> PERF_SAMPLE_WEIGHT = 1U << 14,
>> + PERF_SAMPLE_DSRC= 1U << 15,
>>
>> - PERF_SAMPLE_MAX = 1U << 15, /* non-ABI */
>> -
>> + PERF_SAMPLE_MAX = 1U << 16, /* non-ABI */
>> };
>>
>> /*
>> @@ -591,6 +591,7 @@ enum perf_event_type {
>>*u64 dyn_size; } && PERF_SAMPLE_STACK_USER
>>*
>>* { u64 weight; } && PERF_SAMPLE_WEIGHT
>> + * { u64 dsrc; } && PERF_SAMPLE_DSRC
>>* };
>>*/
>> PERF_RECORD_SAMPLE = 9,
>> @@ -616,4 +617,67 @@ enum perf_callchain_context {
>> #define PERF_FLAG_FD_OUTPUT (1U << 1)
>> #define PERF_FLAG_PID_CGROUP (1U << 2) /* pid=cgroup id, per-cpu
>> mode only */
>>
>> +union perf_mem_dsrc {
>> + __u64 val;
>> + struct {
>> + __u64 mem_op:5, /* type of opcode */
>> + mem_lvl:14, /* memory hierarchy level */
>> + mem_snoop:5,/* snoop mode */
>> + mem_lock:2, /* lock instr */
>> + mem_dtlb:7, /* tlb access */
>> + mem_rsvd:31;
>> + };
>> +};
>> +
>> +/* type of opcode (load/store/prefetch,code) */
>> +#define PERF_MEM_OP_NA 0x01 /* not available */
>> +#define PERF_MEM_OP_LOAD 0x02 /* load instruction */
>> +#define PERF_MEM_OP_STORE0x04 /* store instruction */
>> +#define PERF_MEM_OP_PFETCH 0x08 /* prefetch */
>> +#define PERF_MEM_OP_EXEC 0x10 /* code (execution) */
>> +#define PERF_MEM_OP_SHIFT0
>> +
>> +/* memory hierarchy (memory level, hit or miss) */
>> +#define PERF_MEM_LVL_NA 0x01 /* not available */
>> +#define PERF_MEM_LVL_HIT 0x02 /* hit level */
>> +#define PERF_MEM_LVL_MISS0x04 /* miss level */
>> +#define PERF_MEM_LVL_L1 0x08 /* L1 */
>> +#define PERF_MEM_LVL_LFB 0x10 /* Line Fill Buffer */
>> +#define PERF_MEM_LVL_L2 0x20 /* L2 hit */
>> +#define PERF_MEM_LVL_L3 0x40 /* L3 hit */
>> +#define PERF_MEM_LVL_LOC_RAM 0x80 /* Local DRAM */
>> +#define PERF_MEM_LVL_REM_RAM10x100 /* Remote DRAM (1 hop) */
>> +#define PERF_MEM_LVL_REM_RAM20x200 /* Remote DRAM (2 hops) */
>> +#define PERF_MEM_LVL_REM_CCE10x400 /* Remote Cache (1 hop) */
>> +#define PERF_MEM_LVL_REM_CCE20x800 /* Remote Cache (2 hops) */
>> +#define PERF_MEM_LVL_IO 0x1000 /* I/O memory */
>> +#define PERF_MEM_LVL_UNC 0x2000 /* Uncached memory */
>> +#define PERF_MEM_LVL_SHIFT 5
>> +
>> +/* snoop mode */
>> +#define PERF_MEM_SNOOP_NA0x01 /* not available */
>> +#define PERF_MEM_SNOOP_NONE 0x02 /* no snoop */
>> +#define PERF_MEM_SNOOP_HIT 0x04 /* snoop hit */
>> +#define PERF_MEM_SNOOP_MISS 0x08 /* snoop miss */
>> +#define PERF_MEM_SNOOP_HITM 0x10 /* snoop hit modified */
>> +#define PERF_MEM_SNOOP_SHIFT 19
>> +
>> +/* locked instruction */
>> +#define
[PATCH 2/5] ARM: compressed/head.S: work around new binutils warning
In August 2012, Matthew Gretton-Dann checked a change into binutils labelled "Error on obsolete & warn on deprecated registers", apparently as part of ARMv8 support. Apparently, this was supposed to emit the message "Warning: This coprocessor register access is deprecated in ARMv8" when using certain mcr/mrc instructions and building for ARMv8. Unfortunately, the message that is actually emitted appears to be '(null)', which is less helpful in comparison. Even more unfortunately, this is biting us on every single kernel build with a new gas, because arch/arm/boot/compressed/head.S and some other files in that directory are built with -march=all since kernel commit 80cec14a8 "[ARM] Add -march=all to assembly file build in arch/arm/boot/compressed" back in v2.6.28. This patch reverts Russell's nice solution and replaces it with a more complex one that sprinkles .arch statements inside of the head.S file in functions that are executed in different architecture levels, which seems to solve the original problem just as well, and gets rid of the new one, too. Without this patch, building anything results in: arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:565: Warning: (null) arch/arm/boot/compressed/head.S:676: Warning: (null) arch/arm/boot/compressed/head.S:698: Warning: (null) arch/arm/boot/compressed/head.S:722: Warning: (null) arch/arm/boot/compressed/head.S:726: Warning: (null) arch/arm/boot/compressed/head.S:957: Warning: (null) arch/arm/boot/compressed/head.S:996: Warning: (null) arch/arm/boot/compressed/head.S:997: Warning: (null) arch/arm/boot/compressed/head.S:1027: Warning: (null) arch/arm/boot/compressed/head.S:1035: Warning: (null) arch/arm/boot/compressed/head.S:1046: Warning: (null) arch/arm/boot/compressed/head.S:1060: Warning: (null) arch/arm/boot/compressed/head.S:1092: Warning: (null) arch/arm/boot/compressed/head.S:1094: Warning: (null) arch/arm/boot/compressed/head.S:1095: Warning: (null) arch/arm/boot/compressed/head.S:1102: Warning: (null) arch/arm/boot/compressed/head.S:1134: Warning: (null) Signed-off-by: Arnd Bergmann Cc: Matthew Gretton-Dann Cc: Russell King --- arch/arm/boot/compressed/Makefile | 2 +- arch/arm/boot/compressed/head.S | 12 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index 5cad8a6..dfe5687 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -121,7 +121,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS)) endif ccflags-y := -fpic -fno-builtin -I$(obj) -asflags-y := -Wa,-march=all -DZIMAGE +asflags-y := -DZIMAGE # Supply kernel BSS size to the decompressor via a linker symbol. KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \ diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index fe4d9c3..3b0b21a 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -548,6 +548,7 @@ cache_on: mov r3, #8 @ cache_on function * to cover all 32bit address and cacheable and bufferable. */ __armv4_mpu_cache_on: + .arch armv4 mov r0, #0x3f @ 4G, the whole mcr p15, 0, r0, c6, c7, 0 @ PR7 Area Setting mcr p15, 0, r0, c6, c7, 1 @@ -655,6 +656,7 @@ ENDPROC(__setup_mmu) @ Enable unaligned access on v6, to allow better code generation @ for the decompressor C code: __armv6_mmu_cache_on: + .arch armv6 mrc p15, 0, r0, c1, c0, 0 @ read SCTLR bic r0, r0, #2 @ A (no unaligned access fault) orr r0, r0, #1 << 22@ U (v6 unaligned access model) @@ -663,11 +665,13 @@ __armv6_mmu_cache_on: __arm926ejs_mmu_cache_on: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH + .arch armv5 mov r0, #4 @ put dcache in WT mode mcr p15, 7, r0, c15, c0, 0 #endif __armv4_mmu_cache_on: + .arch armv4 mov r12, lr #ifdef CONFIG_MMU mov r6, #CB_BITS | 0x12 @ U @@ -688,6 +692,7 @@ __armv4_mmu_cache_on: mov pc, r12 __armv7_mmu_cache_on: + .arch armv7-a mov r12, lr #ifdef CONFIG_MMU mrc p15, 0, r11, c0, c1, 4 @ read ID_MMFR0 @@ -1031,6 +1036,7 @@ cache_clean_flush: mov r3, #16 b call_cache_fn + .arch armv4 __armv4_mpu_cache_flush: mov r2, #1 mov r3, #0 @@ -1056,6 +1062,7 @@ __fa526_cache_flush: mov pc, lr __armv6_mmu_cache_flush: + .arch armv6 mov r1, #0 mcr p15, 0, r1, c7, c14, 0 @ clean+invalidate D mcr p15, 0, r1, c7, c5, 0 @ invalidate I+BTB @@
Re: [PATCH] ACPI / scan: Make it clear that acpi_bus_trim() cannot fail
On Thu, 2013-01-24 at 23:56 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Since acpi_bus_trim() cannot fail, change its definition to a void
> function, so that its callers don't check the return value in vain
> and update the callers.
>
> Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Thanks,
-Toshi
> ---
>
> On top of current linux-pm.git/linux-next.
>
> Thanks,
> Rafael
>
> ---
> drivers/acpi/dock.c|8 ++--
> drivers/acpi/scan.c| 12 +++-
> drivers/pci/hotplug/acpiphp_glue.c | 10 +++---
> include/acpi/acpi_bus.h|2 +-
> 4 files changed, 9 insertions(+), 23 deletions(-)
>
> Index: linux-pm/drivers/acpi/scan.c
> ===
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -127,13 +127,8 @@ void acpi_bus_hot_remove_device(void *co
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "Hot-removing device %s...\n", dev_name(>dev)));
>
> - if (acpi_bus_trim(device)) {
> - printk(KERN_ERR PREFIX
> - "Removing device failed\n");
> - goto err_out;
> - }
> -
> - /* device has been freed */
> + acpi_bus_trim(device);
> + /* Device node has been released. */
> device = NULL;
>
> /* power off device */
> @@ -1656,7 +1651,7 @@ static acpi_status acpi_bus_remove(acpi_
> return AE_OK;
> }
>
> -int acpi_bus_trim(struct acpi_device *start)
> +void acpi_bus_trim(struct acpi_device *start)
> {
> /*
>* Execute acpi_bus_device_detach() as a post-order callback to detach
> @@ -1672,7 +1667,6 @@ int acpi_bus_trim(struct acpi_device *st
> acpi_walk_namespace(ACPI_TYPE_ANY, start->handle, ACPI_UINT32_MAX, NULL,
> acpi_bus_remove, NULL, NULL);
> acpi_bus_remove(start->handle, 0, NULL, NULL);
> - return 0;
> }
> EXPORT_SYMBOL_GPL(acpi_bus_trim);
>
> Index: linux-pm/include/acpi/acpi_bus.h
> ===
> --- linux-pm.orig/include/acpi/acpi_bus.h
> +++ linux-pm/include/acpi/acpi_bus.h
> @@ -386,7 +386,7 @@ int acpi_bus_register_driver(struct acpi
> void acpi_bus_unregister_driver(struct acpi_driver *driver);
> int acpi_bus_scan(acpi_handle handle);
> void acpi_bus_hot_remove_device(void *context);
> -int acpi_bus_trim(struct acpi_device *start);
> +void acpi_bus_trim(struct acpi_device *start);
> acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
> int acpi_match_device_ids(struct acpi_device *device,
> const struct acpi_device_id *ids);
> Index: linux-pm/drivers/acpi/dock.c
> ===
> --- linux-pm.orig/drivers/acpi/dock.c
> +++ linux-pm/drivers/acpi/dock.c
> @@ -336,13 +336,9 @@ static struct acpi_device * dock_create_
> static void dock_remove_acpi_device(acpi_handle handle)
> {
> struct acpi_device *device;
> - int ret;
>
> - if (!acpi_bus_get_device(handle, )) {
> - ret = acpi_bus_trim(device);
> - if (ret)
> - pr_debug("error removing bus, %x\n", -ret);
> - }
> + if (!acpi_bus_get_device(handle, ))
> + acpi_bus_trim(device);
> }
>
> /**
> Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> ===
> --- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
> +++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> @@ -742,8 +742,7 @@ static int acpiphp_bus_add(struct acpiph
> /* this shouldn't be in here, so remove
>* the bus then re-add it...
>*/
> - ret_val = acpi_bus_trim(device);
> - dbg("acpi_bus_trim return %x\n", ret_val);
> + acpi_bus_trim(device);
> }
>
> ret_val = acpi_bus_scan(func->handle);
> @@ -772,11 +771,8 @@ static int acpiphp_bus_trim(acpi_handle
> return retval;
> }
>
> - retval = acpi_bus_trim(device);
> - if (retval)
> - err("cannot remove from acpi list\n");
> -
> - return retval;
> + acpi_bus_trim(device);
> + return 0;
> }
>
> static void acpiphp_set_acpi_region(struct acpiphp_slot *slot)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] drm/exynos: don't include plat/gpio-cfg.h
Patch 9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM" allowed building the exynos hdmi driver on non-samsung platforms, which unfortunately broke compilation in combination with 22c4f42897 "drm: exynos: hdmi: add support for exynos5 hdmi", which added an inclusion of the samsung-specific plat/gpio-cfg.h header file. Fortunately, that header file is not required any more here, so we can simply revert the inclusion in order to build the ARM allyesconfig again without getting this error: drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory Signed-off-by: Arnd Bergmann Cc: Rob Clark Cc: Inki Dae Cc: Kyungmin Park Cc: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_hdmi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 41ff79d..b5f5119 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -34,7 +34,6 @@ #include #include #include -#include #include -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] ARM build regressions in 3.8
This is what remains from my previous 15 patch series, the other patches have largely been obsoleted by fixes from other people that found the same issues. The samsung and w90x900 fixes should probably go through the arm-soc tree, while I'd hope James Morris to pick up the seccomp one and Dave Airlie to take the exynos drm patch, but we can also put both into arm-soc if that makes their lifes easier. On the compressed/head.S patch, I'm still awaiting feedback. It's not urgent since it is only a warning. Arnd Bergmann (5): samples/seccomp: be less stupid about cross compiling ARM: compressed/head.S: work around new binutils warning ARM: samsung: fix assembly syntax for new gas ARM: w90x900: fix legacy assembly syntax drm/exynos: don't include plat/gpio-cfg.h arch/arm/boot/compressed/Makefile| 2 +- arch/arm/boot/compressed/head.S | 12 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++-- arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++-- arch/arm/mach-s3c24xx/pm-h1940.S | 2 +- arch/arm/mach-s3c24xx/sleep-s3c2410.S| 12 ++-- arch/arm/mach-s3c24xx/sleep-s3c2412.S| 12 ++-- arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++-- arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 1 - samples/seccomp/Makefile | 2 ++ 11 files changed, 47 insertions(+), 34 deletions(-) -- 1.7.10.4 Cc: Ben Dooks Cc: David Airlie Cc: James Morris Cc: Rob Clark Cc: Russell King Cc: dri-de...@lists.freedesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] ARM: samsung: fix assembly syntax for new gas
Recent assembler versions complain about extraneous whitespace inside [] brackets. This fixes all of these instances for the samsung platforms. We should backport this to all kernels that might need to be built with new binutils. arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]' arch/arm/kernel/debug.S: Assembler messages: arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x5600)-(0x5000))+(0xF600+(0x0100-((0)+(((0x5600)-(0x5000))+(0xF600+(0x0100]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x5600)-(0x5000))+(0xF600+(0x0100-((0)+(((0x5600)-(0x5000))+(0xF600+(0x0100]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages: arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x5600)-(0x5000))+(0xF600+(0x0100-(((0x5600)-(0x5000))+(0xF600+(0x0100)))]' arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' Signed-off-by: Arnd Bergmann Cc: Ben Dooks Cc: Kukjin Kim Cc: sta...@vger.kernel.org --- arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++-- arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++-- arch/arm/mach-s3c24xx/pm-h1940.S | 2 +- arch/arm/mach-s3c24xx/sleep-s3c2410.S| 12 ++-- arch/arm/mach-s3c24xx/sleep-s3c2412.S| 12 ++-- arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +- 6 files changed, 30 insertions(+), 30 deletions(-) diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S index 4135de8..13ed33c 100644 --- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S +++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S @@ -40,17 +40,17 @@ addeq \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART) addne \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART) bic \rd, \rd, #0xff000 - ldr \rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ] + ldr \rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)] and \rd, \rd, #0x00ff teq \rd, #0x0044@ is it 2440? 1004: - ldr \rd, [ \rx, # S3C2410_UFSTAT ] + ldr \rd, [\rx, # S3C2410_UFSTAT] moveq \rd, \rd, lsr #SHIFT_2440TXF tst \rd, #S3C2410_UFSTAT_TXFULL .endm .macro fifo_full_s3c2410 rd, rx - ldr \rd, [ \rx, # S3C2410_UFSTAT ] + ldr \rd, [\rx, # S3C2410_UFSTAT] tst \rd, #S3C2410_UFSTAT_TXFULL .endm @@ -68,18 +68,18
[PATCH 4/5] ARM: w90x900: fix legacy assembly syntax
New ARM binutils don't allow extraneous whitespace inside of brackets, which causes this error on all mach-w90x900 defconfigs: arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]' arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]' This removes the whitespace in order to build the kernel again. Signed-off-by: Arnd Bergmann Cc: Wan ZongShun --- arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-w90x900/include/mach/entry-macro.S b/arch/arm/mach-w90x900/include/mach/entry-macro.S index e286dac..0ff612a 100644 --- a/arch/arm/mach-w90x900/include/mach/entry-macro.S +++ b/arch/arm/mach-w90x900/include/mach/entry-macro.S @@ -19,8 +19,8 @@ mov \base, #AIC_BA - ldr \irqnr, [ \base, #AIC_IPER] - ldr \irqnr, [ \base, #AIC_ISNR] + ldr \irqnr, [\base, #AIC_IPER] + ldr \irqnr, [\base, #AIC_ISNR] cmp \irqnr, #0 .endm -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] samples/seccomp: be less stupid about cross compiling
The seccomp filters are currently built for the build host, not for the machine that they are going to run on, but they are also built for with the -m32 flag if the kernel is built for a 32 bit machine, both of which seems rather odd. It broke allyesconfig on my machine, which is x86-64, but building for 32 bit ARM, with this error message: In file included from /usr/include/stdio.h:28:0, from samples/seccomp/bpf-fancy.c:15: /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory because there are no 32 bit libc headers installed on this machine. We should really be building all the samples for the target machine rather than the build host, but since the infrastructure for that appears to be missing right now, let's be a little bit smarter and not pass the '-m32' flag to the HOSTCC when cross- compiling. Signed-off-by: Arnd Bergmann Acked-by: Kees Cook Cc: Heiko Carstens Cc: James Morris --- samples/seccomp/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile index bbbd276..7203e66 100644 --- a/samples/seccomp/Makefile +++ b/samples/seccomp/Makefile @@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o # Try to match the kernel target. ifndef CONFIG_64BIT +ifndef CROSS_COMPILE # s390 has -m31 flag to build 31 bit binaries ifndef CONFIG_S390 @@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG) HOSTLOADLIBES_bpf-fancy += $(MFLAG) HOSTLOADLIBES_dropper += $(MFLAG) endif +endif # Tell kbuild to always build the programs always := $(hostprogs-y) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] lpc_ich: fix gpio base and control offsets
On Fri, 2013-01-25 at 08:44 -0500, Peter Hurley wrote:
> On Fri, 2013-01-25 at 10:47 +0100, Linus Walleij wrote:
> > On Thu, Jan 24, 2013 at 9:52 PM, Aaron Sierra wrote:
> >
> > > In ICH5 and earlier the GPIOBASE and GPIOCTRL registers are found at
> > > offsets 0x58 and 0x5C, respectively. This patch allows GPIO access to
> > > properly be enabled (and disabled) for these chipsets.
> > >
> > > Signed-off-by: Agócs Pál
> > > Signed-off-by: Aaron Sierra
> >
> > OK... Paul, can you test this on your setup?
> >
> > > @@ -858,14 +874,35 @@ wdt_done:
> > > static int lpc_ich_probe(struct pci_dev *dev,
> > > const struct pci_device_id *id)
> > > {
> > > + struct lpc_ich_priv *priv;
> > > int ret;
> > > bool cell_added = false;
> > >
> > > - ret = lpc_ich_init_wdt(dev, id);
> > > + priv = kmalloc(GFP_KERNEL, sizeof(struct lpc_ich_priv));
> > > + if (!priv)
> > > + return -ENOMEM;
> > > +
> > > + priv->chipset = id->driver_data;
> >
> > So where is this id->driver_data which is just assigned to
> > priv->chipset coming from again? ACPI something?
>
> That's how pci device probing works.
>
> The driver defines a struct pci_device_id[] table with
> DEFINE_PCI_DEVICE_TABLE(), initializing the .driver_data fields with an
> index into a static array of device types (in this case, struct
> lpc_ich_info lpc_chipset_info[]), and the pci subsystem passes the
> actual matching pci_device_id* to the driver's probe() function.
>
> There's more information in Documentation/pci.txt
Correction. Documentation/PCI/pci.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/18] perf: add memory access sampling support
On Fri, Jan 25, 2013 at 9:55 AM, Ingo Molnar wrote: > > * Stephane Eranian wrote: > >> This patch series had a new feature to the kernel perf_events >> interface and corresponding user level tool, perf. > > Can I add your Signed-off-by tag to the patches you picked up > from Andi? > Yes. But note that I have to simplify one of them because it included TSX changes. It's the following patch: [PATCH v7 05/18] perf, tools: Add support for weight v7 (modified) I was going to suggest to him that he breaks his original into two or move it earlier in his stack so has to make it independent of HSW specific extensions. > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tracepoint] cargo-culting considered harmful...
On Fri, 2013-01-25 at 09:38 -0500, Mathieu Desnoyers wrote:
> Yep, I'd be OK with removing this example, since now all users are
> expected to user TRACE_EVENT(), which is built on top of tracepoints.
Can I get your Acked-by for the following patch?
-- Steve
commit 867a31fab0a064e54147371425f9fdef933e3d1d
Author: Steven Rostedt
Date: Fri Jan 25 09:46:36 2013 -0500
tracing: Remove tracepoint sample code
The tracepoint sample code was used to teach developers how to
create their own tracepoints. But now the trace_events have been
added as a higher level that is used directly by developers today.
Only the trace_event code should use the tracepoint interface
directly and no new tracepoints should be added.
Besides, the example had a race condition with the use of the
->d_name.name dentry field, as pointed out by Al Viro.
Best just to remove the code so it wont be used by other developers.
Cc: Al Viro
Cc: Mathieu Desnoyers
Signed-off-by: Steven Rostedt
diff --git a/samples/Kconfig b/samples/Kconfig
index 7b6792a..6181c2c 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -5,12 +5,6 @@ menuconfig SAMPLES
if SAMPLES
-config SAMPLE_TRACEPOINTS
- tristate "Build tracepoints examples -- loadable modules only"
- depends on TRACEPOINTS && m
- help
- This build tracepoints example modules.
-
config SAMPLE_TRACE_EVENTS
tristate "Build trace_events examples -- loadable modules only"
depends on EVENT_TRACING && m
diff --git a/samples/Makefile b/samples/Makefile
index 5ef08bb..1a60c62 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -1,4 +1,4 @@
# Makefile for Linux samples code
-obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ tracepoints/ trace_events/ \
+obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ \
hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/
diff --git a/samples/tracepoints/Makefile b/samples/tracepoints/Makefile
deleted file mode 100644
index 36479ad..000
--- a/samples/tracepoints/Makefile
+++ /dev/null
@@ -1,6 +0,0 @@
-# builds the tracepoint example kernel modules;
-# then to use one (as root): insmod
-
-obj-$(CONFIG_SAMPLE_TRACEPOINTS) += tracepoint-sample.o
-obj-$(CONFIG_SAMPLE_TRACEPOINTS) += tracepoint-probe-sample.o
-obj-$(CONFIG_SAMPLE_TRACEPOINTS) += tracepoint-probe-sample2.o
diff --git a/samples/tracepoints/tp-samples-trace.h
b/samples/tracepoints/tp-samples-trace.h
deleted file mode 100644
index 4d46be9..000
--- a/samples/tracepoints/tp-samples-trace.h
+++ /dev/null
@@ -1,11 +0,0 @@
-#ifndef _TP_SAMPLES_TRACE_H
-#define _TP_SAMPLES_TRACE_H
-
-#include /* for struct inode and struct file */
-#include
-
-DECLARE_TRACE(subsys_event,
- TP_PROTO(struct inode *inode, struct file *file),
- TP_ARGS(inode, file));
-DECLARE_TRACE_NOARGS(subsys_eventb);
-#endif
diff --git a/samples/tracepoints/tracepoint-probe-sample.c
b/samples/tracepoints/tracepoint-probe-sample.c
deleted file mode 100644
index 744c0b9..000
--- a/samples/tracepoints/tracepoint-probe-sample.c
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- * tracepoint-probe-sample.c
- *
- * sample tracepoint probes.
- */
-
-#include
-#include
-#include
-#include "tp-samples-trace.h"
-
-/*
- * Here the caller only guarantees locking for struct file and struct inode.
- * Locking must therefore be done in the probe to use the dentry.
- */
-static void probe_subsys_event(void *ignore,
- struct inode *inode, struct file *file)
-{
- path_get(>f_path);
- dget(file->f_path.dentry);
- printk(KERN_INFO "Event is encountered with filename %s\n",
- file->f_path.dentry->d_name.name);
- dput(file->f_path.dentry);
- path_put(>f_path);
-}
-
-static void probe_subsys_eventb(void *ignore)
-{
- printk(KERN_INFO "Event B is encountered\n");
-}
-
-static int __init tp_sample_trace_init(void)
-{
- int ret;
-
- ret = register_trace_subsys_event(probe_subsys_event, NULL);
- WARN_ON(ret);
- ret = register_trace_subsys_eventb(probe_subsys_eventb, NULL);
- WARN_ON(ret);
-
- return 0;
-}
-
-module_init(tp_sample_trace_init);
-
-static void __exit tp_sample_trace_exit(void)
-{
- unregister_trace_subsys_eventb(probe_subsys_eventb, NULL);
- unregister_trace_subsys_event(probe_subsys_event, NULL);
- tracepoint_synchronize_unregister();
-}
-
-module_exit(tp_sample_trace_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Mathieu Desnoyers");
-MODULE_DESCRIPTION("Tracepoint Probes Samples");
diff --git a/samples/tracepoints/tracepoint-probe-sample2.c
b/samples/tracepoints/tracepoint-probe-sample2.c
deleted file mode 100644
index 9fcf990..000
--- a/samples/tracepoints/tracepoint-probe-sample2.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * tracepoint-probe-sample2.c
- *
- * 2nd sample tracepoint probes.
- */
-
-#include
-#include
-#include
Re: [PATCH v3] lpc_ich: fix gpio base and control offsets
> On Fri, 2013-01-25 at 14:25 +0100, Paul Bolle wrote: > > 0) insmod-ing an updated lpc_ich.ko generated quite a bit of noise > > in > > dmesg: > > <6>[19913.247530] iTCO_wdt: Found a ICH8M-E TCO device > > (Version=2, TCOBASE=0x1060) > > <6>[19913.249310] iTCO_wdt: initialized. heartbeat=30 sec > > (nowayout=0) > > <4>[19913.249332] ACPI Warning: > > 0x1028-0x102f SystemIO conflicts with > > Region \_SB_.PCI0.LPC_.PMIO 1 (20120913/utaddress-251) > > <6>[19913.249338] ACPI: If an ACPI driver is available for this > > device, you should use it instead of the native driver > > <4>[19913.249342] ACPI Warning: > > 0x11b0-0x11bf SystemIO conflicts with > > Region \_SB_.PCI0.LPC_.LPIO 1 (20120913/utaddress-251) > > <6>[19913.249347] ACPI: If an ACPI driver is available for this > > device, you should use it instead of the native driver > > <4>[19913.249349] ACPI Warning: > > 0x1180-0x11af SystemIO conflicts with > > Region \_SB_.PCI0.LPC_.LPIO 1 (20120913/utaddress-251) > > <6>[19913.249353] ACPI: If an ACPI driver is available for this > > device, you should use it instead of the native driver > > <4>[19913.249355] lpc_ich: Resource conflict(s) found affecting > > gpio_ich > > > > I have no idea whatsoever what that could mean. > > But please note that these messages are nothing new. I found > identical > messages in all my logs (from v3.7.y kernels; I do not seem to have > logs > of older releases anymore). > > > Paul Bolle Paul, My understanding of these warnings is that your BIOS defines regions in its ACPI tables that coincide with regions we want to pass to gpio-ich. Because the regions are defined in the ACPI tables Linux assumes that they are actively being used by the BIOS and that they shouldn't be used, unless you tell the kernel to globally ignore ACPI resource conflicts. Similar warnings used to also appear for the TCO watchdog regions until that was determined to be a regression and the ACPI resource conflict checks were removed by this patch: commit 092369efbd6ef6b4a215741ce9f65446bf45beff Author: Feng Tang Date: Thu Aug 16 15:50:10 2012 +0800 mfd: lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver [trimmed] Actually the same check could be removed for the gpio-ich in lpc_ich.c, but I'm not sure if it will cause problems. Like Feng, I also am not sure if removing the checks for GPIO would cause problems, so the noise remains. -Aaron S. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/2] perf stat: add interval printing
On Fri, Jan 25, 2013 at 3:52 AM, Arnaldo Carvalho de Melo wrote: > Em Tue, Jan 22, 2013 at 02:18:52PM +0100, Stephane Eranian escreveu: >> This patch adds a new printing mode for perf stat. >> It allows internval printing. That means perf stat >> can now print event deltas at regular time interval. >> This is useful to detect phases in programs. > > This patch is not applying to my perf/core branch, does it depend on > some other outstanding patchset from you? > > Tomorrow probably all I had in this area will be in Ingo's tree, but > can you please take a look at my perf/core branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > My patches are always relative to: git://git.kernel.org/pub/scm/linux/kernel/git/tip.tip.git Do you still need to rebase against your tree? > ? > > Regards, > > - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND V5 6/6] perf, amd: Enable northbridge performance counters on AMD family 15h
On Thu, Jan 10, 2013 at 8:50 PM, Jacob Shin wrote: > On AMD family 15h processors, there are 4 new performance counters > (in addition to 6 core performance counters) that can be used for > counting northbridge events (i.e. DRAM accesses). Their bit fields are > almost identical to the core performance counters. However, unlike the > core performance counters, these MSRs are shared between multiple > cores (that share the same northbridge). We will reuse the same code > path as existing family 10h northbridge event constraints handler > logic to enforce this sharing. > > Signed-off-by: Jacob Shin > --- > arch/x86/include/asm/cpufeature.h |2 + > arch/x86/include/asm/perf_event.h |9 ++ > arch/x86/include/uapi/asm/msr-index.h |2 + > arch/x86/kernel/cpu/perf_event_amd.c | 167 > + > 4 files changed, 160 insertions(+), 20 deletions(-) > > diff --git a/arch/x86/include/asm/cpufeature.h > b/arch/x86/include/asm/cpufeature.h > index 2d9075e..93fe929 100644 > --- a/arch/x86/include/asm/cpufeature.h > +++ b/arch/x86/include/asm/cpufeature.h > @@ -167,6 +167,7 @@ > #define X86_FEATURE_TBM(6*32+21) /* trailing bit > manipulations */ > #define X86_FEATURE_TOPOEXT(6*32+22) /* topology extensions CPUID leafs > */ > #define X86_FEATURE_PERFCTR_CORE (6*32+23) /* core performance counter > extensions */ > +#define X86_FEATURE_PERFCTR_NB (6*32+24) /* NB performance counter > extensions */ > > /* > * Auxiliary flags: Linux defined - For features scattered in various > @@ -309,6 +310,7 @@ extern const char * const x86_power_flags[32]; > #define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR) > #define cpu_has_pclmulqdq boot_cpu_has(X86_FEATURE_PCLMULQDQ) > #define cpu_has_perfctr_core boot_cpu_has(X86_FEATURE_PERFCTR_CORE) > +#define cpu_has_perfctr_nb boot_cpu_has(X86_FEATURE_PERFCTR_NB) > #define cpu_has_cx8boot_cpu_has(X86_FEATURE_CX8) > #define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16) > #define cpu_has_eager_fpu boot_cpu_has(X86_FEATURE_EAGER_FPU) > diff --git a/arch/x86/include/asm/perf_event.h > b/arch/x86/include/asm/perf_event.h > index 2234eaaec..57cb634 100644 > --- a/arch/x86/include/asm/perf_event.h > +++ b/arch/x86/include/asm/perf_event.h > @@ -29,9 +29,14 @@ > #define ARCH_PERFMON_EVENTSEL_INV (1ULL << 23) > #define ARCH_PERFMON_EVENTSEL_CMASK0xFF00ULL > > +#define AMD64_EVENTSEL_INT_CORE_ENABLE (1ULL << 36) > #define AMD64_EVENTSEL_GUESTONLY (1ULL << 40) > #define AMD64_EVENTSEL_HOSTONLY(1ULL << 41) > > +#define AMD64_EVENTSEL_INT_CORE_SEL_SHIFT 37 > +#define AMD64_EVENTSEL_INT_CORE_SEL_MASK \ > + (0xFULL << AMD64_EVENTSEL_INT_CORE_SEL_SHIFT) > + Interestingly enough, this bitfield is not yet documented in the public BKDG from March 2012. I assume it will be in the next rev. > #define AMD64_EVENTSEL_EVENT \ > (ARCH_PERFMON_EVENTSEL_EVENT | (0x0FULL << 32)) > #define INTEL_ARCH_EVENT_MASK \ > @@ -46,8 +51,12 @@ > #define AMD64_RAW_EVENT_MASK \ > (X86_RAW_EVENT_MASK | \ > AMD64_EVENTSEL_EVENT) > +#define AMD64_RAW_EVENT_MASK_NB\ > + (AMD64_EVENTSEL_EVENT| \ > +ARCH_PERFMON_EVENTSEL_UMASK) > #define AMD64_NUM_COUNTERS 4 > #define AMD64_NUM_COUNTERS_CORE6 > +#define AMD64_NUM_COUNTERS_NB 4 > > #define ARCH_PERFMON_UNHALTED_CORE_CYCLES_SEL 0x3c > #define ARCH_PERFMON_UNHALTED_CORE_CYCLES_UMASK(0x00 << 8) > diff --git a/arch/x86/include/uapi/asm/msr-index.h > b/arch/x86/include/uapi/asm/msr-index.h > index 433a59f..075a402 100644 > --- a/arch/x86/include/uapi/asm/msr-index.h > +++ b/arch/x86/include/uapi/asm/msr-index.h > @@ -194,6 +194,8 @@ > /* Fam 15h MSRs */ > #define MSR_F15H_PERF_CTL 0xc0010200 > #define MSR_F15H_PERF_CTR 0xc0010201 > +#define MSR_F15H_NB_PERF_CTL 0xc0010240 > +#define MSR_F15H_NB_PERF_CTR 0xc0010241 > > /* Fam 10h MSRs */ > #define MSR_FAM10H_MMIO_CONF_BASE 0xc0010058 > diff --git a/arch/x86/kernel/cpu/perf_event_amd.c > b/arch/x86/kernel/cpu/perf_event_amd.c > index faf9072..1a80e05 100644 > --- a/arch/x86/kernel/cpu/perf_event_amd.c > +++ b/arch/x86/kernel/cpu/perf_event_amd.c > @@ -132,11 +132,14 @@ static u64 amd_pmu_event_map(int hw_event) > return amd_perfmon_event_map[hw_event]; > } > > +static struct event_constraint *amd_nb_event_constraint; > + > /* > * Previously calculated offsets > */ > static unsigned int event_offsets[X86_PMC_IDX_MAX] __read_mostly; > static unsigned int count_offsets[X86_PMC_IDX_MAX] __read_mostly; > +static unsigned int rdpmc_indexes[X86_PMC_IDX_MAX] __read_mostly; > > /* > * Legacy
[PATCH RESEND] goldfish: power device
From: Mike Lockwood
Add the emulated power driver for the Goldfish platform.
This folds together the code from the Google tree, Jun Nakajima's cleanups
and x86 porting work, and then a tidy up to pass checkpatch.
Signed-off-by: Mike A. Chan
[cleanup and x86 support]
Signed-off-by: Sheng Yang
Signed-off-by: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[ported to 3.4]
Signed-off-by: Tom Keel
[ported to 3.7 and final tidy]
Signed-off-by: Alan Cox
---
drivers/power/Kconfig|8 +
drivers/power/Makefile |1
drivers/power/goldfish_battery.c | 234 ++
3 files changed, 242 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/goldfish_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 9f45e2f..0c5208d 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -346,8 +346,14 @@ config AB8500_BM
help
Say Y to include support for AB8500 battery management.
-source "drivers/power/reset/Kconfig"
+config BATTERY_GOLDFISH
+ tristate "Goldfish battery driver"
+ depends on GOLDFISH
+ help
+ Say Y to enable support for the battery and AC power in the
+ Goldfish emulator.
+source "drivers/power/reset/Kconfig"
endif # POWER_SUPPLY
source "drivers/power/avs/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b11e0c7..a9f5c06 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o
obj-$(CONFIG_BATTERY_DS2781) += ds2781_battery.o
obj-$(CONFIG_BATTERY_DS2782) += ds2782_battery.o
+obj-$(CONFIG_BATTERY_GOLDFISH) += goldfish_battery.o
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
diff --git a/drivers/power/goldfish_battery.c b/drivers/power/goldfish_battery.c
new file mode 100644
index 000..e067ab0
--- /dev/null
+++ b/drivers/power/goldfish_battery.c
@@ -0,0 +1,234 @@
+/*
+ * Power supply driver for the goldfish emulator
+ *
+ * Copyright (C) 2008 Google, Inc.
+ * Copyright (C) 2012 Intel, Inc.
+ * Copyright (C) 2013 Intel, Inc.
+ * Author: Mike Lockwood
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+struct goldfish_battery_data {
+ void __iomem *reg_base;
+ int irq;
+ spinlock_t lock;
+
+ struct power_supply battery;
+ struct power_supply ac;
+};
+
+#define GOLDFISH_BATTERY_READ(data, addr) (readl(data->reg_base + addr))
+#define GOLDFISH_BATTERY_WRITE(data, addr, x) (writel(x, data->reg_base +
addr))
+
+
+/* temporary variable used between goldfish_battery_probe() and
goldfish_battery_open() */
+static struct goldfish_battery_data *battery_data;
+
+enum {
+ /* status register */
+ BATTERY_INT_STATUS = 0x00,
+ /* set this to enable IRQ */
+ BATTERY_INT_ENABLE = 0x04,
+
+ BATTERY_AC_ONLINE = 0x08,
+ BATTERY_STATUS = 0x0C,
+ BATTERY_HEALTH = 0x10,
+ BATTERY_PRESENT = 0x14,
+ BATTERY_CAPACITY= 0x18,
+
+ BATTERY_STATUS_CHANGED = 1U << 0,
+ AC_STATUS_CHANGED = 1U << 1,
+ BATTERY_INT_MASK= BATTERY_STATUS_CHANGED | AC_STATUS_CHANGED,
+};
+
+
+static int goldfish_ac_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct goldfish_battery_data *data = container_of(psy,
+ struct goldfish_battery_data, ac);
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = GOLDFISH_BATTERY_READ(data, BATTERY_AC_ONLINE);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int goldfish_battery_get_property(struct power_supply *psy,
+enum power_supply_property psp,
+union power_supply_propval *val)
+{
+ struct goldfish_battery_data *data = container_of(psy,
+ struct goldfish_battery_data, battery);
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ val->intval =
Re: [PATCHv2 1/9] staging: zsmalloc: add gfp flags to zs_create_pool
On 01/24/2013 07:33 PM, Minchan Kim wrote: > Hi Seth, frontswap guys > > On Tue, Jan 8, 2013 at 5:24 AM, Seth Jennings > wrote: >> zs_create_pool() currently takes a gfp flags argument >> that is used when growing the memory pool. However >> it is not used in allocating the metadata for the pool >> itself. That is currently hardcoded to GFP_KERNEL. >> >> zswap calls zs_create_pool() at swapon time which is done >> in atomic context, resulting in a "might sleep" warning. > > I didn't review this all series, really sorry but totday I saw Nitin > added Acked-by so I'm afraid Greg might get it under my radar. I'm not > strong against but I would like know why we should call frontswap_init > under swap_lock? Is there special reason? The call stack is: SYSCALL_DEFINE2(swapon.. <-- swapon_mutex taken here enable_swap_info() <-- swap_lock taken here frontswap_init() __frontswap_init() zswap_frontswap_init() zs_create_pool() It isn't entirely clear to me why frontswap_init() is called under lock. Then again, I'm not entirely sure what the swap_lock protects. There are no comments near the swap_lock definition to tell me. I would guess that the intent is to block any writes to the swap device until frontswap_init() has completed. Dan care to weigh in? Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
Any news? Thnx! azur __ > Od: "Michal Hocko" > Komu: azurIt > Dátum: 30.12.2012 12:08 > Predmet: Re: [PATCH for 3.2.34] memcg: do not trigger OOM from > add_to_page_cache_locked > > CC: linux-kernel@vger.kernel.org, linux...@kvack.org, "cgroups mailinglist" > , "KAMEZAWA Hiroyuki" > , "Johannes Weiner" >On Sun 30-12-12 02:09:47, azurIt wrote: >> >which suggests that the patch is incomplete and that I am blind :/ >> >mem_cgroup_cache_charge calls __mem_cgroup_try_charge for the page cache >> >and that one doesn't check GFP_MEMCG_NO_OOM. So you need the following >> >follow-up patch on top of the one you already have (which should catch >> >all the remaining cases). >> >Sorry about that... >> >> >> This was, again, killing my MySQL server (search for "(mysqld)"): >> http://www.watchdog.sk/lkml/oom_mysqld5 > >grep "Kill process" oom_mysqld5 >Dec 30 01:53:34 server01 kernel: [ 367.061801] Memory cgroup out of memory: >Kill process 5512 (apache2) score 716 or sacrifice child >Dec 30 01:53:35 server01 kernel: [ 367.338024] Memory cgroup out of memory: >Kill process 5517 (apache2) score 718 or sacrifice child >Dec 30 01:53:35 server01 kernel: [ 367.747888] Memory cgroup out of memory: >Kill process 5513 (apache2) score 721 or sacrifice child >Dec 30 01:53:36 server01 kernel: [ 368.159860] Memory cgroup out of memory: >Kill process 5516 (apache2) score 726 or sacrifice child >Dec 30 01:53:36 server01 kernel: [ 368.665606] Memory cgroup out of memory: >Kill process 5520 (apache2) score 733 or sacrifice child >Dec 30 01:53:36 server01 kernel: [ 368.765652] Out of memory: Kill process >1778 (mysqld) score 39 or sacrifice child >Dec 30 01:53:36 server01 kernel: [ 369.101753] Memory cgroup out of memory: >Kill process 5519 (apache2) score 754 or sacrifice child >Dec 30 01:53:37 server01 kernel: [ 369.464262] Memory cgroup out of memory: >Kill process 5583 (apache2) score 762 or sacrifice child >Dec 30 01:53:37 server01 kernel: [ 369.465017] Out of memory: Kill process >5506 (apache2) score 18 or sacrifice child >Dec 30 01:53:37 server01 kernel: [ 369.574932] Memory cgroup out of memory: >Kill process 5523 (apache2) score 759 or sacrifice child > >So your mysqld has been killed by the global OOM not memcg. But why when >you seem to be perfectly fine regarding memory? I guess the following >backtrace is relevant: >Dec 30 01:53:36 server01 kernel: [ 368.569720] DMA: 0*4kB 1*8kB 0*16kB 1*32kB >2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15912kB >Dec 30 01:53:36 server01 kernel: [ 368.570447] DMA32: 9*4kB 10*8kB 8*16kB >6*32kB 5*64kB 6*128kB 4*256kB 2*512kB 3*1024kB 3*2048kB 613*4096kB = 2523636kB >Dec 30 01:53:36 server01 kernel: [ 368.571175] Normal: 5*4kB 2060*8kB >4122*16kB 2550*32kB 2667*64kB 722*128kB 197*256kB 68*512kB 15*1024kB 4*2048kB >1855*4096kB = 8134036kB >Dec 30 01:53:36 server01 kernel: [ 368.571906] 308964 total pagecache pages >Dec 30 01:53:36 server01 kernel: [ 368.572023] 0 pages in swap cache >Dec 30 01:53:36 server01 kernel: [ 368.572140] Swap cache stats: add 0, >delete 0, find 0/0 >Dec 30 01:53:36 server01 kernel: [ 368.572260] Free swap = 0kB >Dec 30 01:53:36 server01 kernel: [ 368.572375] Total swap = 0kB >Dec 30 01:53:36 server01 kernel: [ 368.597836] apache2 invoked oom-killer: >gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0 >Dec 30 01:53:36 server01 kernel: [ 368.598034] apache2 cpuset=uid >mems_allowed=0 >Dec 30 01:53:36 server01 kernel: [ 368.598152] Pid: 5385, comm: apache2 Not >tainted 3.2.35-grsec #1 >Dec 30 01:53:36 server01 kernel: [ 368.598273] Call Trace: >Dec 30 01:53:36 server01 kernel: [ 368.598396] [] >dump_header+0x7e/0x1e0 >Dec 30 01:53:36 server01 kernel: [ 368.598516] [] ? >find_lock_task_mm+0x2f/0x70 >Dec 30 01:53:36 server01 kernel: [ 368.598638] [] >oom_kill_process+0x85/0x2a0 >Dec 30 01:53:36 server01 kernel: [ 368.598759] [] >out_of_memory+0xe5/0x200 >Dec 30 01:53:36 server01 kernel: [ 368.598880] [] >pagefault_out_of_memory+0xbd/0x110 >Dec 30 01:53:36 server01 kernel: [ 368.599006] [] >mm_fault_error+0xb6/0x1a0 >Dec 30 01:53:36 server01 kernel: [ 368.599127] [] >do_page_fault+0x3ee/0x460 >Dec 30 01:53:36 server01 kernel: [ 368.599250] [] ? >mntput+0x1f/0x30 >Dec 30 01:53:36 server01 kernel: [ 368.599371] [] ? >fput+0x156/0x200 >Dec 30 01:53:36 server01 kernel: [ 368.599496] [] >page_fault+0x1f/0x30 > >This would suggest that an unexpected ENOMEM leaked during page fault >path. I do not see which one could that be because you said THP >(CONFIG_TRANSPARENT_HUGEPAGE) are disabled (and the other patch I have >mentioned in the thread should fix that issue - btw. the patch is >already scheduled for stable tree). > __do_fault, do_anonymous_page and do_wp_page call >mem_cgroup_newpage_charge with GFP_KERNEL which means that >we do memcg OOM and never return ENOMEM. do_swap_page calls >mem_cgroup_try_charge_swapin with
[PATCH] block/partition/msdos: detect AIX formatted disks even without 55aa
AIX formatted disks do not always have the MSDOS 55aa signature.
This happens e.g. for unbootable AIX disks.
Up to now, such disks were not recognized as AIX disks, because of the
missing 55aa. Fix that by inverting the two tests. Let's first
check for the AIX magic strings, and only if that fails check for
the MSDOS magic word.
Signed-off-by: Philippe De Muyter
---
block/partitions/msdos.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 8752a5d..4b31ed7 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -455,14 +455,15 @@ int msdos_partition(struct parsed_partitions *state)
data = read_part_sector(state, 0, );
if (!data)
return -1;
- if (!msdos_magic_present(data + 510)) {
+
+ if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+ strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
- if (aix_magic_present(state, data)) {
+ if (!msdos_magic_present(data + 510)) {
put_dev_sector(sect);
- strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
Hi, On Fri, Jan 25, 2013 at 12:29:43PM +, Mark Rutland wrote: > > > > + depending upon omap4 or omap5. > > > > + - reg-names: The names of the register addresses corresponding to the > > > > registers > > > > + filled in "reg". > > > > + - ti,type: This is used to differentiate whether the control module > > > > has > > > > + usb mailbox or usb3 phy power. omap4 has usb mailbox in control > > > > module to > > > > + notify events to the musb core and omap5 has usb3 phy power > > > > register to > > > > + power on usb3 phy. Should be "1" if it has mailbox and "2" if it > > > > has usb3 > > > > + phy power. > > > > > > Why not make this a string property, perhaps values "mailbox" or > > > "register"? > > > > NAK. > > Can I ask what your objection to using a string property is? > > As far as I can see, "ti,type" is only used by this driver, so there's no > common convention to stick to. Using a string makes the binding easier for > humans to read, and thus harder to mess up in a dts, and it decouples the > binding from kernel-side constants. IIRC there is some work going on to add #define-like support for DT, which would allow us to match against integers while still having meaningful symbolic representations. -- balbi signature.asc Description: Digital signature
[PATCH 1/1] digsig: Fix memory leakage in digsig_verify_rsa()
From: YOSHIFUJI Hideaki digsig_verify_rsa() does not free kmalloc'ed buffer returned by mpi_get_buffer(). Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: Dmitry Kasatkin Cc: sta...@vger.kernel.org --- lib/digsig.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/digsig.c b/lib/digsig.c index 8c0e629..dc2be7e 100644 --- a/lib/digsig.c +++ b/lib/digsig.c @@ -162,6 +162,8 @@ static int digsig_verify_rsa(struct key *key, memset(out1, 0, head); memcpy(out1 + head, p, l); + kfree(p); + err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, ); if (err) goto err; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tracepoint] cargo-culting considered harmful...
* Al Viro (v...@zeniv.linux.org.uk) wrote:
> On Wed, Jan 23, 2013 at 03:51:47PM -0800, Andrew Morton wrote:
>
> > > note that
> > > * file->f_path is already pinned down by open(), path_get() does not
> > > provide anything extra.
> > > * file->f_path.dentry is already pinned by open() *and* path_get()
> > > just above that dget().
> > > * ->d_name.name *IS* *NOT* *PROTECTED* by pinning dentry down,
> > > whether it's done once or thrice.
> >
> > I guess the first two are obvious (or at least, expected). But the
> > third isn't.
Hi Al,
I agree that the tracepoint example should be removed. There is one
extra piece of module code I think would require fixing (see below).
>
> ->d_name.name is changed by rename() (as one could expect). Grabbing
> a reference to dentry will not prevent rename() from happening. ->i_mutex
> on parent will, but you either need to play with retries (grab reference
> to parent, grab ->i_mutex, check that it's still our parent, if we'd lost
> the race and someone had renamed the sucker - unlock ->i_mutex, dput,
> repeat) *or* to have our dentry looked up with parent locked, with ->i_mutex
> on said parent still held (which happens to cover the majority of valid
> uses in fs code - ->lookup(), ->create(), ->unlink(), rename(), etc. are
> all called that way, so the name of dentry passed to such methods is stable
> for the duration of the method).
>
> ->d_lock on dentry is also sufficient, but that obviously means that you
> can't block while holding it.
>
> > Where should a kernel developer go to learn these things?
> > include/linux/dcache.h doesn't mention d_name locking rules, nor does
> > Documentation/filesystems/vfs.txt.
>
> See directory locking rules in there; the crucial point is that dentry
> name is changed by rename() *and* that results of a race can be worse than
> just running into a partially rewritten name - long names are allocated
> separately and walking through a stale pointer you might end up in freed
> memory.
>
> It's a mess, unfortunately, and $BIGNUM other uses of ->i_mutex make it only
> nastier. Once in a while I go hunting for races in that area, usally with
> a bunch of fixes coming out of such run ;-/
In the light of what you are saying here, am I right to think that the
following code is broken wrt locking wrt use of
filp->f_dentry->d_name.name ?
static
void lttng_enumerate_task_fd(struct lttng_session *session,
struct task_struct *p, char *tmp)
{
struct fdtable *fdt;
struct file *filp;
unsigned int i;
const unsigned char *path;
task_lock(p);
if (!p->files)
goto unlock_task;
spin_lock(>files->file_lock);
fdt = files_fdtable(p->files);
for (i = 0; i < fdt->max_fds; i++) {
filp = fcheck_files(p->files, i);
if (!filp)
continue;
path = d_path(>f_path, tmp, PAGE_SIZE);
/* Make sure we give at least some info */
trace_lttng_statedump_file_descriptor(session, p, i,
IS_ERR(path) ?
filp->f_dentry->d_name.name :
path);
}
spin_unlock(>files->file_lock);
unlock_task:
task_unlock(p);
}
Since tracepoints never block, holding the ->d_lock around the
trace_lttng_statedump_file_descriptor() tracepoint should probably be
enough to make it correct. Am I missing anything ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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 v1 0/6] USB: Add support for multiple PHYs of same type
Hi Kishon, On Thu, Jan 24, 2013 at 17:21:45, Mohammed, Afzal wrote: > On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote: > > On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote: > > > USB first instance of am335x works in mainline as of now. > > > Can you check if this series indeed breaks am335x? > > > > Thanks for your help. > > Do you have a tree having these changes, it would be easier for me. I tried with your "omap5-with-palmas" branch that was mentioned in the cover letter of your latest series (but couldn't find the commit that you mentioned in the cover letter, HEAD of that branch that I tested was "2c29519 ARM: dts: palmas: update dt data for palmas-usb") usb first instance of am335x works as earlier. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [tracepoint] cargo-culting considered harmful...
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Wed, Jan 23, 2013 at 10:55:24PM +, Al Viro wrote:
> > In samples/tracepoints/tracepoint-probe-sample.c:
> > /*
> > * Here the caller only guarantees locking for struct file and struct inode.
> > * Locking must therefore be done in the probe to use the dentry.
> > */
> > static void probe_subsys_event(void *ignore,
> >struct inode *inode, struct file *file)
> > {
> > path_get(>f_path);
> > dget(file->f_path.dentry);
> > printk(KERN_INFO "Event is encountered with filename %s\n",
> > file->f_path.dentry->d_name.name);
> > dput(file->f_path.dentry);
> > path_put(>f_path);
> > }
> >
> > note that
> > * file->f_path is already pinned down by open(), path_get() does not
> > provide anything extra.
> > * file->f_path.dentry is already pinned by open() *and* path_get()
> > just above that dget().
> > * ->d_name.name *IS* *NOT* *PROTECTED* by pinning dentry down,
> > whether it's done once or thrice.
> >
> > I do realize that it's just an example, but perhaps we should rename that
> > file to match the contents? The only question is whether it should be
> > git mv samples/tracepoints/{tracepoint-probe-sample,cargo-cult}.c
> > or git mv samples cargo-cult...
>
> I wonder if we should just remove the samples/tracepoints/ all together.
> The tracepoint code is now only used internally by the trace_event code,
> and there should not be any users of tracepoints directly.
Yep, I'd be OK with removing this example, since now all users are
expected to user TRACE_EVENT(), which is built on top of tracepoints.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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 09/19] mfd/twl4030: don't warn about uninitialized return code
On Fri, Jan 25, 2013 at 2:14 PM, Arnd Bergmann wrote:
> If the twl4030_write_script function gets called with
> a zero length argument, its return value does not
> get set. We know that all scripts have a nonzero
> length, but returning an error in case they ever
> do is probably appropriate.
>
> Without this patch, building omap2plus_defconfig results in:
>
> drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
> drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in
> this function
Reviewed-by: Amit Kucheria
> Signed-off-by: Arnd Bergmann
> Cc: Samuel Ortiz
> Cc: Peter Ujfalusi
> Cc: Kevin Hilman
> Cc: Amit Kucheria
> ---
> drivers/mfd/twl4030-power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 4dae241..dd362c1 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -159,7 +159,7 @@ out:
> static int twl4030_write_script(u8 address, struct twl4030_ins *script,
>int len)
> {
> - int err;
> + int err = -EINVAL;
>
> for (; len; len--, address++, script++) {
> if (len == 1) {
> --
> 1.8.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code
On Friday 25 January 2013 15:25:03 Peter Ujfalusi wrote: > On 01/25/2013 03:14 PM, Arnd Bergmann wrote: > > If the twl4030_write_script function gets called with > > a zero length argument, its return value does not > > get set. We know that all scripts have a nonzero > > length, but returning an error in case they ever > > do is probably appropriate. > > > > Without this patch, building omap2plus_defconfig results in: > > > > drivers/mfd/twl4030-power.c: In function 'load_twl4030_script': > > drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized > > in this function > > I've fixed up Kevin's email since he is no longer with TI and added Tero to > the CC list since this is *something*-power on OMAP platforms > > Reviewed-by: Peter Ujfalusi Thanks! I also got the mailing list address wrong on all mails, so I'll retransmit the whole series in a bit, just waiting for other quick comments to come in. 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: [PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code
On 01/25/2013 03:14 PM, Arnd Bergmann wrote:
> If the twl4030_write_script function gets called with
> a zero length argument, its return value does not
> get set. We know that all scripts have a nonzero
> length, but returning an error in case they ever
> do is probably appropriate.
>
> Without this patch, building omap2plus_defconfig results in:
>
> drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
> drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in
> this function
I've fixed up Kevin's email since he is no longer with TI and added Tero to
the CC list since this is *something*-power on OMAP platforms ;)
Reviewed-by: Peter Ujfalusi
> Signed-off-by: Arnd Bergmann
> Cc: Samuel Ortiz
> Cc: Peter Ujfalusi
> Cc: Kevin Hilman
> Cc: Amit Kucheria
> ---
> drivers/mfd/twl4030-power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 4dae241..dd362c1 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -159,7 +159,7 @@ out:
> static int twl4030_write_script(u8 address, struct twl4030_ins *script,
> int len)
> {
> - int err;
> + int err = -EINVAL;
>
> for (; len; len--, address++, script++) {
> if (len == 1) {
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/19] oss/dmabuf: use dma_map_single
The virt_to_bus/bus_to_virt functions have been deprecated for as long as I can remember, and they are used in very few remaining instances, usually in obscure ISA device drivers. The OSS sound drivers are the only ones that are still used on the ARM architecture, and only on some of the earliest StrongARM machines. The problem for converting the OSS subsystem to use dma_map_single instead is that the caller of virt_to_bus does not have a device pointer, since the subsystem has never been ported to use the common device infrastructure. Signed-off-by: Arnd Bergmann Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: alsa-de...@alsa-project.org --- sound/oss/dmabuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c index bcc3e8e..a59c888 100644 --- a/sound/oss/dmabuf.c +++ b/sound/oss/dmabuf.c @@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap) } } dmap->raw_buf = start_addr; - dmap->raw_buf_phys = virt_to_bus(start_addr); + dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL); for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++) SetPageReserved(page); @@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap) for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++) ClearPageReserved(page); + dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL); free_pages((unsigned long) dmap->raw_buf, sz); dmap->raw_buf = NULL; } -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/19] sched/debug: fix format string for 32 bit platforms
The type returned from atomic64_t can be either unsigned long or unsigned long long, depending on the architecture. Using a cast to unsigned long long lets us use the same format string for all architectures. Without this patch, building with scheduler debugging enabled results in: kernel/sched/debug.c: In function 'print_cfs_rq': kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat] kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat] Signed-off-by: Arnd Bergmann Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Paul Turner --- kernel/sched/debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 2cd3c1b..7ae4c4c 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -222,8 +222,8 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq->runnable_load_avg); SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", cfs_rq->blocked_load_avg); - SEQ_printf(m, " .%-30s: %ld\n", "tg_load_avg", - atomic64_read(_rq->tg->load_avg)); + SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg", + (unsigned long long)atomic64_read(_rq->tg->load_avg)); SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", cfs_rq->tg_load_contrib); SEQ_printf(m, " .%-30s: %d\n", "tg_runnable_contrib", -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init
The device IDs are referenced by the driver and potentially
used beyond the init time, as kbuild correctly warns
about. Remove the __initconst annotation.
Without this patch, building at91_dt_defconfig results in:
WARNING: drivers/watchdog/built-in.o(.data+0x28): Section mismatch in reference
from the variable at91wdt_driver to the (unknown reference)
.init.rodata:(unknown)
The variable at91wdt_driver references
the (unknown reference) __initconst (unknown)
Signed-off-by: Arnd Bergmann
Cc: Wim Van Sebroeck
Cc: linux-watch...@vger.kernel.org
Cc: Nicolas Ferre
Cc: Fabio Porcedda
---
drivers/watchdog/at91sam9_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index dc42e44..6dad954 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -304,7 +304,7 @@ static int __exit at91wdt_remove(struct platform_device
*pdev)
}
#if defined(CONFIG_OF)
-static const struct of_device_id at91_wdt_dt_ids[] __initconst = {
+static const struct of_device_id at91_wdt_dt_ids[] = {
{ .compatible = "atmel,at91sam9260-wdt" },
{ /* sentinel */ }
};
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/19] ARM: common warning fixes
Hi everyone, This series fixes all the known build warnings on ARM with any of the defconfig files. Most of these patches are regressions and warn about code that changed in linux-3.8, so it would be nice to fix those before the release. The patch for the ARM_UNWIND warning is added here for completeness: The warning is old and particularly annoying, but the patch is not ready for inclusion. I have more patches like these for less important issues, in four classes: 1. warnings and errors that are only present in linux-next 2. warnings about allyesconfig/allnoconfig/allmodconfig builds. 3. warnings and errors for various randconfig combinations 4. 'maybe-uninitialized' gcc warnings that only appear with gcc-3.7 or 3.8. There are quite a lot of them. I will get to those once this series is sorted out. Since there are no interdepencies between the patches, my preference is to have them applied by the individual subsystem maintainers. Anything that has not at least made it into linux-next by the next merge window and has not received a 'NAK' or been obsoleted by another patch, I plan to submit as part of an arm-soc branch for 3.9. Arnd Arnd Bergmann (18): ARM: shmobile: fix defconfig warning on CONFIG_USB ARM: disable virt_to_bus/virt_to_bus almost everywhere ARM: msm: proc_comm_boot_wait should not be __init oss/dmabuf: use dma_map_single sched: warnings in kernel/sched/fair.c sched/debug: fix format string for 32 bit platforms scripts/sortextable: silence script output lockdep: avoid warning about unused variables mfd/twl4030: don't warn about uninitialized return code watchdog: at91sam9: at91_wdt_dt_ids cannot be __init regmap: avoid undefined return from regmap_read_debugfs pinctrl: exynos: don't mark probing functions as __init pinctrl: nomadik: nmk_prcm_gpiocr_get_mode may be unused spi/atmel: remove incorrect __exit_p() sunrpc: don't warn for unused variable 'buf' mac80211: avoid a build warning input/joystick: use get_cycles on ARM ARM: at91: suspend both memory controllers on at91sam9263 sahara (1): [INCOMPLETE] ARM: make return_address available for ARM_UNWIND arch/arm/Kconfig | 4 arch/arm/configs/marzen_defconfig| 1 - arch/arm/configs/shark_defconfig | 1 - arch/arm/include/asm/dma.h | 2 +- arch/arm/include/asm/ftrace.h| 6 ++ arch/arm/include/asm/memory.h| 2 ++ arch/arm/kernel/Makefile | 12 +--- arch/arm/kernel/return_address.c | 10 +++--- arch/arm/kernel/stacktrace.c | 3 +++ arch/arm/mach-at91/cpuidle.c | 2 +- arch/arm/mach-at91/pm.c | 2 +- arch/arm/mach-at91/pm.h | 8 arch/arm/mach-msm/proc_comm.h| 2 +- drivers/base/regmap/regmap-debugfs.c | 2 +- drivers/input/joystick/analog.c | 8 ++-- drivers/mfd/twl4030-power.c | 2 +- drivers/pinctrl/pinctrl-exynos5440.c | 10 +- drivers/pinctrl/pinctrl-nomadik.c| 2 +- drivers/spi/spi-atmel.c | 2 +- drivers/watchdog/at91sam9_wdt.c | 2 +- include/linux/lockdep.h | 2 +- kernel/sched/debug.c | 4 ++-- kernel/sched/fair.c | 2 +- kernel/trace/trace_irqsoff.c | 26 -- net/mac80211/tx.c| 8 net/sunrpc/svc.c | 2 +- scripts/sortextable.h| 2 +- sound/oss/dmabuf.c | 3 ++- 28 files changed, 59 insertions(+), 73 deletions(-) -- 1.8.0 Cc: Greg Kroah-Hartman Cc: Ingo Molnar Cc: Linus Walleij Cc: Mark Brown Cc: Nicolas Ferre Cc: Peter Zijlstra Cc: Russell King Cc: Samuel Ortiz Cc: net...@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/19] pinctrl: exynos: don't mark probing functions as __init
Functions called from a driver probe() method must not be
marked __init, because they may get called after the
init phase is done, when the device shows up late, or
because of deferred probing.
Without this patch, building exynos_defconfig results in
multiple warnings like:
WARNING: drivers/pinctrl/built-in.o(.text+0x51bc): Section mismatch in
reference from the function exynos5440_pinctrl_probe() to the function
.init.text:exynos5440_gpiolib_register()
The function exynos5440_pinctrl_probe() references
the function __init exynos5440_gpiolib_register().
This is often because exynos5440_pinctrl_probe lacks a __init
annotation or the annotation of exynos5440_gpiolib_register is wrong.
Signed-off-by: Arnd Bergmann
Cc: Linus Walleij
Cc: Tomasz Figa
Cc: Kukjin Kim
---
drivers/pinctrl/pinctrl-exynos5440.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-exynos5440.c
b/drivers/pinctrl/pinctrl-exynos5440.c
index de05b64..1427299 100644
--- a/drivers/pinctrl/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/pinctrl-exynos5440.c
@@ -599,7 +599,7 @@ static int exynos5440_gpio_direction_output(struct
gpio_chip *gc, unsigned offse
}
/* parse the pin numbers listed in the 'samsung,exynos5440-pins' property */
-static int __init exynos5440_pinctrl_parse_dt_pins(struct platform_device
*pdev,
+static int exynos5440_pinctrl_parse_dt_pins(struct platform_device *pdev,
struct device_node *cfg_np, unsigned int **pin_list,
unsigned int *npins)
{
@@ -630,7 +630,7 @@ static int __init exynos5440_pinctrl_parse_dt_pins(struct
platform_device *pdev,
* Parse the information about all the available pin groups and pin functions
* from device node of the pin-controller.
*/
-static int __init exynos5440_pinctrl_parse_dt(struct platform_device *pdev,
+static int exynos5440_pinctrl_parse_dt(struct platform_device *pdev,
struct exynos5440_pinctrl_priv_data *priv)
{
struct device *dev = >dev;
@@ -723,7 +723,7 @@ static int __init exynos5440_pinctrl_parse_dt(struct
platform_device *pdev,
}
/* register the pinctrl interface with the pinctrl subsystem */
-static int __init exynos5440_pinctrl_register(struct platform_device *pdev,
+static int exynos5440_pinctrl_register(struct platform_device *pdev,
struct exynos5440_pinctrl_priv_data *priv)
{
struct device *dev = >dev;
@@ -798,7 +798,7 @@ static int __init exynos5440_pinctrl_register(struct
platform_device *pdev,
}
/* register the gpiolib interface with the gpiolib subsystem */
-static int __init exynos5440_gpiolib_register(struct platform_device *pdev,
+static int exynos5440_gpiolib_register(struct platform_device *pdev,
struct exynos5440_pinctrl_priv_data *priv)
{
struct gpio_chip *gc;
@@ -831,7 +831,7 @@ static int __init exynos5440_gpiolib_register(struct
platform_device *pdev,
}
/* unregister the gpiolib interface with the gpiolib subsystem */
-static int __init exynos5440_gpiolib_unregister(struct platform_device *pdev,
+static int exynos5440_gpiolib_unregister(struct platform_device *pdev,
struct exynos5440_pinctrl_priv_data *priv)
{
int ret = gpiochip_remove(priv->gc);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/19] ARM: disable virt_to_bus/virt_to_bus almost everywhere
We are getting a number of warnings about the use of the deprecated
bus_to_virt function in drivers using the ARM ISA DMA API:
drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
(declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]
This is only because that function gets used by the inline
set_dma_addr() helper. We know that any driver for the ISA DMA API
is correctly using the DMA addresses, so we can change this
to use the __bus_to_virt() function instead, which does not warn.
After this, there are no remaining drivers that are used on
any defconfigs on ARM using virt_to_bus or bus_to_virt, with
the exception of the OSS sound driver. That driver is only used
on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
on all other platforms and hide the deprecated functions, which
is far more effective than marking them as deprecated, in order
to avoid any new users of that code.
Signed-off-by: Arnd Bergmann
Cc: Russell King
---
arch/arm/Kconfig | 4
arch/arm/configs/shark_defconfig | 1 -
arch/arm/include/asm/dma.h | 2 +-
arch/arm/include/asm/memory.h| 2 ++
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..91d4aea 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1450,6 +1450,10 @@ config ISA_DMA
bool
select ISA_DMA_API
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+ depends on !ARCH_RPC && !ARCH_NETWINDER && !ARCH_SHARK
+
# Select ISA DMA interface
config ISA_DMA_API
bool
diff --git a/arch/arm/configs/shark_defconfig b/arch/arm/configs/shark_defconfig
index caa07db..e319b2c 100644
--- a/arch/arm/configs/shark_defconfig
+++ b/arch/arm/configs/shark_defconfig
@@ -73,7 +73,6 @@ CONFIG_PARTITION_ADVANCED=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_ISO8859_1=m
-# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index 5694a0d..58b8c6a 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -105,7 +105,7 @@ extern void set_dma_sg(unsigned int chan, struct
scatterlist *sg, int nr_sg);
*/
extern void __set_dma_addr(unsigned int chan, void *addr);
#define set_dma_addr(chan, addr) \
- __set_dma_addr(chan, bus_to_virt(addr))
+ __set_dma_addr(chan, (void *)__bus_to_virt(addr))
/* Set the DMA byte count for this channel
*
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 73cf03a..b11105c 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -245,6 +245,7 @@ static inline void *phys_to_virt(phys_addr_t x)
#define __bus_to_pfn(x)__phys_to_pfn(x)
#endif
+#ifdef CONFIG_VIRT_TO_BUS
static inline __deprecated unsigned long virt_to_bus(void *x)
{
return __virt_to_bus((unsigned long)x);
@@ -254,6 +255,7 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
{
return (void *)__bus_to_virt(x);
}
+#endif
/*
* Conversion between a struct page and a physical address.
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'
When RPC_DEBUG is unset, the dprintk() macro does nothing,
causing the 'buf' variable in svc_printk to become unused.
Marking it as __maybe_unused avoids a harmless gcc warning.
Without this patch, building at91_dt_defconfig results in:
net/sunrpc/svc.c: In function 'svc_printk':
net/sunrpc/svc.c:1051:7: warning: unused variable 'buf' [-Wunused-variable]
Signed-off-by: Arnd Bergmann
Cc: "J. Bruce Fields"
Cc: Trond Myklebust
Cc: linux-...@vger.kernel.org
Cc: net...@vger.kernel.org
---
net/sunrpc/svc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index dbf12ac..b1f5223 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1047,7 +1047,7 @@ void svc_printk(struct svc_rqst *rqstp, const char *fmt,
...)
{
struct va_format vaf;
va_list args;
- charbuf[RPC_MAX_ADDRBUFLEN];
+ char buf[RPC_MAX_ADDRBUFLEN] __maybe_unused;
va_start(args, fmt);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/19] ARM: msm: proc_comm_boot_wait should not be __init
msm_smd_probe is a driver probe function and may get
called after the __init time, so it must not call
any __init function, as the link-time warning reports.
Take away the __init annotation on proc_comm_boot_wait
to fix this.
Without this patch, building msm_defconfig results in:
WARNING: vmlinux.o(.text+0xb048): Section mismatch in reference from the
function msm_smd_probe() to the function .init.text:proc_comm_boot_wait()
The function msm_smd_probe() references
the function __init proc_comm_boot_wait().
This is often because msm_smd_probe lacks a __init
annotation or the annotation of proc_comm_boot_wait is wrong.
Signed-off-by: Arnd Bergmann
Cc: David Brown
Cc: Bryan Huntsman
Cc: Daniel Walker
Cc: linux-arm-...@vger.kernel.org
---
arch/arm/mach-msm/proc_comm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-msm/proc_comm.h b/arch/arm/mach-msm/proc_comm.h
index 12da4ca..e8d043a 100644
--- a/arch/arm/mach-msm/proc_comm.h
+++ b/arch/arm/mach-msm/proc_comm.h
@@ -253,6 +253,6 @@ enum {
(((drvstr) & 0xF) << 17))
int msm_proc_comm(unsigned cmd, unsigned *data1, unsigned *data2);
-void __init proc_comm_boot_wait(void);
+void proc_comm_boot_wait(void);
#endif
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/19] mac80211: avoid a build warning
On Fri, 2013-01-25 at 14:14 +, Arnd Bergmann wrote: > gcc cannot prove that the value of sdata->vif.type does not > change between the switch() statement and the second > comparison to NL80211_IFTYPE_AP, causing a harmless > warning. > Slightly reordering the code makes the warning go away > with no functional change. Thanks! Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 05/19] sched: warnings in kernel/sched/fair.c
a4c96ae319 "sched: Unthrottle rt runqueues in __disable_runtime()"
turned the unthrottle_offline_cfs_rqs function into a static symbol,
which now triggers a warning about it being potentially unused:
kernel/sched/fair.c:2055:13: warning: 'unthrottle_offline_cfs_rqs' defined but
not used [-Wunused-function]
Marking it __maybe_unused shuts up the gcc warning and lets the
compiler safely drop the function body when it's not being used.
To reproduce, build the ARM bcm2835_defconfig.
Signed-off-by: Arnd Bergmann
Cc: Peter Boonstoppel
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Ingo Molnar
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5eea870..81fa536 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2663,7 +2663,7 @@ static void destroy_cfs_bandwidth(struct cfs_bandwidth
*cfs_b)
hrtimer_cancel(_b->slack_timer);
}
-static void unthrottle_offline_cfs_rqs(struct rq *rq)
+static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
{
struct cfs_rq *cfs_rq;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: sahara
This is a reminder that we still need to fix the return_address
function to work correctly with the unwinder. Keun-O Park has
made this attempt in the past, which is still under discussion[1],
and Dave Martin has also mentioned that he would provide a
solution for this problem.
Right now, this patch makes the warning go away and provides
an implementation of return_address for the arm unwinder, but
causes other problems, so we should *not* apply it. I will
keep sending this patch until we have a better solution.
[1] http://lkml.org/lkml/2013/1/11/493
Original changelog:
This fixes a warning saying:
warning: #warning "TODO: return_address should use unwind tables"
And, this enables return_address using unwind information. If ARM_UNWIND is
selected, unwind_frame in unwind.c will be called in walk_stackframe.
Signed-off-by: sahara
Signed-off-by: Arnd Bergmann
Cc: Dave Martin
Cc: Steven Rostedt
Cc: Russell King
---
arch/arm/include/asm/ftrace.h| 6 ++
arch/arm/kernel/Makefile | 12 +---
arch/arm/kernel/return_address.c | 10 +++---
arch/arm/kernel/stacktrace.c | 3 +++
kernel/trace/trace_irqsoff.c | 26 --
5 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index f89515a..3552ad9 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -32,13 +32,11 @@ extern void ftrace_call_old(void);
#ifndef __ASSEMBLY__
-#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
+#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_ARM_UNWIND)
/*
* return_address uses walk_stackframe to do it's work. If both
* CONFIG_FRAME_POINTER=y and CONFIG_ARM_UNWIND=y walk_stackframe uses unwind
- * information. For this to work in the function tracer many functions would
- * have to be marked with __notrace. So for now just depend on
- * !CONFIG_ARM_UNWIND.
+ * information.
*/
void *return_address(unsigned int);
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5bbec7b..09a0d64 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -5,13 +5,11 @@
CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
AFLAGS_head.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
-ifdef CONFIG_FUNCTION_TRACER
-CFLAGS_REMOVE_ftrace.o = -pg
-CFLAGS_REMOVE_insn.o = -pg
-CFLAGS_REMOVE_patch.o = -pg
-endif
-
-CFLAGS_REMOVE_return_address.o = -pg
+CFLAGS_REMOVE_ftrace.o = -pg
+CFLAGS_REMOVE_insn.o = -pg
+CFLAGS_REMOVE_patch.o = -pg
+CFLAGS_REMOVE_unwind.o = -pg
+CFLAGS_REMOVE_return_address.o = -pg
# Object file lists.
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..ccb5e37 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -11,7 +11,7 @@
#include
#include
-#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
+#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_ARM_UNWIND)
#include
#include
@@ -56,17 +56,13 @@ void *return_address(unsigned int level)
return NULL;
}
-#else /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) */
-
-#if defined(CONFIG_ARM_UNWIND)
-#warning "TODO: return_address should use unwind tables"
-#endif
+#else /* CONFIG_FRAME_POINTER || CONFIG_ARM_UNWIND */
void *return_address(unsigned int level)
{
return NULL;
}
-#endif /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) /
else */
+#endif /* CONFIG_FRAME_POINTER || CONFIG_ARM_UNWIND */
EXPORT_SYMBOL_GPL(return_address);
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index 00f79e5..aab144b 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -6,6 +6,9 @@
#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
/*
+ * If both CONFIG_FRAME_POINTER=y and CONFIG_ARM_UNWIND=y walk_stackframe uses
+ * unwind information. So for now just depend on !CONFIG_ARM_UNWIND.
+ *
* Unwind the current stack frame and store the new register values in the
* structure passed as argument. Unwinding is equivalent to a function return,
* hence the new PC value rather than LR should be used for backtrace.
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 713a2ca..6f207ed 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -483,20 +483,6 @@ inline void print_irqtrace_events(struct task_struct *curr)
/*
* We are only interested in hardirq on/off events:
*/
-void trace_hardirqs_on(void)
-{
- if (!preempt_trace() && irq_trace())
- stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL(trace_hardirqs_on);
-
-void trace_hardirqs_off(void)
-{
- if (!preempt_trace() && irq_trace())
- start_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL(trace_hardirqs_off);
-
[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263
For the past three years, we have had a #warning in
mach-at91 about the sdram_selfrefresh_enable or
at91sam9_standby functions possibly not working on
at91sam9263. In the meantime a function was added
to do the right thing on at91sam9g45, which looks like
it should also work on '9263.
This patch blindly removes the warning and changes the
at91sam9263 to use the same code at at91sam9g45, which
may or may not be the right solution. If it is not,
maybe someone could provide a better fix.
Signed-off-by: Arnd Bergmann
Cc: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard
Cc: Andrew Victor
Cc: Albin Tonnerre
Cc: Daniel Lezcano
---
arch/arm/mach-at91/cpuidle.c | 2 +-
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-at91/pm.h | 8
3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..208d486 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -36,7 +36,7 @@ static int at91_enter_idle(struct cpuidle_device *dev,
{
if (cpu_is_at91rm9200())
at91rm9200_standby();
- else if (cpu_is_at91sam9g45())
+ else if (cpu_is_at91sam9g45() || cpu_is_at91sam9263())
at91sam9g45_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..f6bd4fa 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -265,7 +265,7 @@ static int at91_pm_enter(suspend_state_t state)
*/
if (cpu_is_at91rm9200())
at91rm9200_standby();
- else if (cpu_is_at91sam9g45())
+ else if (cpu_is_at91sam9g45() || cpu_is_at91sam9263())
at91sam9g45_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..5252216 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,14 +70,6 @@ static inline void at91sam9g45_standby(void)
at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
}
-#ifdef CONFIG_SOC_AT91SAM9263
-/*
- * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
- * handle those cases both here and in the Suspend-To-RAM support.
- */
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
-
static inline void at91sam9_standby(void)
{
u32 saved_lpr, lpr;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/19] scripts/sortextable: silence script output
The exception table sorter outputs one line every time
it gets called, e.g. 'sort done marker at 66dc00', which
is slightly annoying when doing 'make -s' which is otherwise
completely silent. Since that output is not helpful to
most people building the kernel, turn it off by default.
Signed-off-by: Arnd Bergmann
Cc: David Daney
Cc: "H. Peter Anvin"
---
scripts/sortextable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/sortextable.h b/scripts/sortextable.h
index e4fd45b..f5eb43d 100644
--- a/scripts/sortextable.h
+++ b/scripts/sortextable.h
@@ -182,7 +182,7 @@ do_func(Elf_Ehdr *ehdr, char const *const fname,
table_sort_t custom_sort)
_r(_needed_sym->st_value) -
_r(_needed_sec->sh_addr);
-#if 1
+#if 0
printf("sort done marker at %lx\n",
(unsigned long)((char *)sort_done_location - (char *)ehdr));
#endif
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/19] pinctrl: nomadik: nmk_prcm_gpiocr_get_mode may be unused
nmk_prcm_gpiocr_get_mode is only needed for debugfs output at
the moment, which can be compile-time disabled. Marking
the function __maybe_unused still gives us compile-time
coverage, but avoids a gcc warning.
Without this patch, building nhk8815_defconfig results in:
drivers/pinctrl/pinctrl-nomadik.c:676:12: warning: 'nmk_prcm_gpiocr_get_mode'
defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann
Cc: Jean-Nicolas Graux
Cc: Linus Walleij
Cc: Srinidhi Kasagar
---
drivers/pinctrl/pinctrl-nomadik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c
b/drivers/pinctrl/pinctrl-nomadik.c
index 1bb16ff..5767b18 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -676,7 +676,7 @@ int nmk_gpio_set_mode(int gpio, int gpio_mode)
}
EXPORT_SYMBOL(nmk_gpio_set_mode);
-static int nmk_prcm_gpiocr_get_mode(struct pinctrl_dev *pctldev, int gpio)
+static int __maybe_unused nmk_prcm_gpiocr_get_mode(struct pinctrl_dev
*pctldev, int gpio)
{
int i;
u16 reg;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs
Gcc warns about the case where regmap_read_debugfs tries
to walk an empty map->debugfs_off_cache list, which results
in uninitialized variable getting returned.
Setting this variable to 0 first avoids the warning and
the potentially undefined value.
Without this patch, building mxs_defconfig results in:
drivers/base/regmap/regmap-debugfs.c: In function 'regmap_read_debugfs':
drivers/base/regmap/regmap-debugfs.c:147:9: : warning: 'ret' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Arnd Bergmann
Cc: Mark Brown
Cc: Greg Kroah-Hartman
---
drivers/base/regmap/regmap-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 46a213a..31cc656 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -80,7 +80,7 @@ static unsigned int regmap_debugfs_get_dump_start(struct
regmap *map,
{
struct regmap_debugfs_off_cache *c = NULL;
loff_t p = 0;
- unsigned int i, ret;
+ unsigned int i, ret = 0;
/*
* If we don't have a cache build one so we don't have to do a
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code
If the twl4030_write_script function gets called with
a zero length argument, its return value does not
get set. We know that all scripts have a nonzero
length, but returning an error in case they ever
do is probably appropriate.
Without this patch, building omap2plus_defconfig results in:
drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in
this function
Signed-off-by: Arnd Bergmann
Cc: Samuel Ortiz
Cc: Peter Ujfalusi
Cc: Kevin Hilman
Cc: Amit Kucheria
---
drivers/mfd/twl4030-power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 4dae241..dd362c1 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -159,7 +159,7 @@ out:
static int twl4030_write_script(u8 address, struct twl4030_ins *script,
int len)
{
- int err;
+ int err = -EINVAL;
for (; len; len--, address++, script++) {
if (len == 1) {
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/19] input/joystick: use get_cycles on ARM
ARM normally has an accurate clock source, so
we can theoretically use analog joysticks more
accurately and at the same time avoid the
build warning
#warning Precise timer not defined for this architecture.
from the joystick driver.
Now, why anybody would use that driver no ARM I have no
idea, but Ben Dooks enabled it in the s3c2410_defconfig
along with a bunch of other drivers, even though that
platform has neither ISA nor PCI support. It still
seems to be the right thing to fix this quirk.
Signed-off-by: Arnd Bergmann
Cc: Dmitry Torokhov
Cc: Vojtech Pavlik
Cc: Ben Dooks
---
drivers/input/joystick/analog.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index 358cd7e..9c3e3c1 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -158,14 +158,10 @@ static unsigned int get_time_pit(void)
#define GET_TIME(x)rdtscl(x)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "TSC"
-#elif defined(__alpha__)
+#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM)
#define GET_TIME(x)do { x = get_cycles(); } while (0)
#define DELTA(x,y) ((y)-(x))
-#define TIME_NAME "PCC"
-#elif defined(CONFIG_MN10300)
-#define GET_TIME(x)do { x = get_cycles(); } while (0)
-#define DELTA(x, y)((x) - (y))
-#define TIME_NAME "TSC"
+#define TIME_NAME "get_cycles"
#else
#define FAKE_TIME
static unsigned long analog_faketime = 0;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/19] spi/atmel: remove incorrect __exit_p()
Since we no longer allow building without hotplug, the
atmel_spi_remove function is always present and we should
not use __exit_p() to refer to it.
Without this patch, building at91_dt_defconfig results in:
drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not
used [-Wunused-function]
Signed-off-by: Arnd Bergmann
Cc: Nicolas Ferre
Cc: Grant Likely
Cc: spi-devel-gene...@lists.sourceforge.net
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..656d137 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
.suspend= atmel_spi_suspend,
.resume = atmel_spi_resume,
.probe = atmel_spi_probe,
- .remove = __exit_p(atmel_spi_remove),
+ .remove = atmel_spi_remove,
};
module_platform_driver(atmel_spi_driver);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/19] mac80211: avoid a build warning
gcc cannot prove that the value of sdata->vif.type does not change between the switch() statement and the second comparison to NL80211_IFTYPE_AP, causing a harmless warning. Slightly reordering the code makes the warning go away with no functional change. Without this patch, building ARM at91sam9g45_defconfig with gcc-4.6 results in: net/mac80211/tx.c: In function 'ieee80211_subif_start_xmit': net/mac80211/tx.c:1797:22: warning: 'chanctx_conf' may be used uninitialized in this function [-Wuninitialized] Signed-off-by: Arnd Bergmann Cc: Johannes Berg Cc: "John W. Linville" Cc: "David S. Miller" Cc: linux-wirel...@vger.kernel.org Cc: net...@vger.kernel.org --- net/mac80211/tx.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index e9eadc4..df589bf 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1784,16 +1784,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb, break; /* fall through */ case NL80211_IFTYPE_AP: + if (sdata->vif.type == NL80211_IFTYPE_AP) + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); + if (!chanctx_conf) + goto fail_rcu; fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS); /* DA BSSID SA */ memcpy(hdr.addr1, skb->data, ETH_ALEN); memcpy(hdr.addr2, sdata->vif.addr, ETH_ALEN); memcpy(hdr.addr3, skb->data + ETH_ALEN, ETH_ALEN); hdrlen = 24; - if (sdata->vif.type == NL80211_IFTYPE_AP) - chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); - if (!chanctx_conf) - goto fail_rcu; band = chanctx_conf->def.chan->band; break; case NL80211_IFTYPE_WDS: -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/19] lockdep: avoid warning about unused variables
When lockdep is disabled, a call to lockdep_assert_held
does not use its argument, which results in a compiler
warning if nothing else in the same function uses
that variable. An instance of this was introduced
by c9a49628819 "nfsd: make client_lock per net".
Without this patch, building ARM cerfcube_defconfig results in:
fs/nfsd/nfs4state.c: In function 'free_client':
fs/nfsd/nfs4state.c:1047:19: error: unused variable 'nn' [-Wunused-variable]
Signed-off-by: Arnd Bergmann
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Stanislav Kinsbursky
---
include/linux/lockdep.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 2bca44b..f05631e 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -410,7 +410,7 @@ struct lock_class_key { };
#define lockdep_depth(tsk) (0)
-#define lockdep_assert_held(l) do { } while (0)
+#define lockdep_assert_held(l) do { (void)(l); } while (0)
#define lockdep_recursing(tsk) (0)
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/19] ARM: shmobile: fix defconfig warning on CONFIG_USB
A recent update to the marzen_defconfig introduced a duplicate CONFIG_USB=y line. This removes one of the two. arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB Signed-off-by: Arnd Bergmann Cc: Simon Horman Cc: linux...@vger.kernel.org --- arch/arm/configs/marzen_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig index 728a43c..afb17d6 100644 --- a/arch/arm/configs/marzen_defconfig +++ b/arch/arm/configs/marzen_defconfig @@ -83,7 +83,6 @@ CONFIG_USB=y CONFIG_USB_RCAR_PHY=y CONFIG_MMC=y CONFIG_MMC_SDHI=y -CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PLATFORM=y -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3]scripts/tags.sh: Add ctags magic for declarations of popular kernel type
1)Add magic for declarations of variables of popular kernel type
like spinlock_t, list_head, wait_queue_head_t and other.
2)Add a set of specially handled declaration extentions
like __attribute, __aligned and other.
3)Simplify pci_bus_* magic
Signed-off-by: Kirill V Tkhai
Cc: Michal Marek
CC: Andrew Morton
---
scripts/tags.sh | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 4c53b7d..26a87e6 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -149,12 +149,17 @@ dogtags()
exuberant()
{
all_target_sources | xargs $1 -a\
- -I __initdata,__exitdata,__acquires,__releases \
- -I __read_mostly,cacheline_aligned \
+ -I __initdata,__exitdata,__initconst,__devinitdata \
+ -I __devinitconst,__cpuinitdata,__initdata_memblock \
+ -I __refdata,__attribute\
+ -I __acquires,__releases,__deprecated \
+ -I __read_mostly,__aligned,cacheline_aligned\
-I cacheline_aligned_in_smp \
-I cacheline_internodealigned_in_smp\
+ -I __used,__packed,__packed2__,__must_check,__must_hold \
-I EXPORT_SYMBOL,EXPORT_SYMBOL_GPL \
-I DEFINE_TRACE,EXPORT_TRACEPOINT_SYMBOL,EXPORT_TRACEPOINT_SYMBOL_GPL \
+ -I static,const \
--extra=+f --c-kinds=+px\
--regex-asm='/^(ENTRY|_GLOBAL)\(([^)]*)\).*/\2/'\
--regex-c='/^SYSCALL_DEFINE[[:digit:]]?\(([^,)]*).*/sys_\1/' \
@@ -182,8 +187,19 @@ exuberant()
--regex-c++='/TESTCLEARFLAG_FALSE\(([^,)]*).*/TestClearPage\1/' \
--regex-c++='/__TESTCLEARFLAG_FALSE\(([^,)]*).*/__TestClearPage\1/' \
--regex-c++='/_PE\(([^,)]*).*/PEVENT_ERRNO__\1/'\
-
--regex-c='/PCI_OP_READ\(([a-z]*[a-z]).*[1-4]\)/pci_bus_read_config_\1/' \
-
--regex-c='/PCI_OP_WRITE\(([a-z]*[a-z]).*[1-4]\)/pci_bus_write_config_\1/'
+ --regex-c='/PCI_OP_READ\((\w*).*[1-4]\)/pci_bus_read_config_\1/' \
+ --regex-c='/PCI_OP_WRITE\((\w*).*[1-4]\)/pci_bus_write_config_\1/' \
+ --regex-c='/DEFINE_(MUTEX|SEMAPHORE|SPINLOCK)\((\w*)/\2/v/' \
+ --regex-c='/DEFINE_(RAW_SPINLOCK|RWLOCK|SEQLOCK)\((\w*)/\2/v/' \
+ --regex-c='/DECLARE_(RWSEM|COMPLETION)\((\w*)/\2/v/'\
+ --regex-c='/DECLARE_BITMAP\((\w*)/\1/v/'\
+ --regex-c='/(^|\s)(|L|H)LIST_HEAD\((\w*)/\3/v/' \
+ --regex-c='/(^|\s)RADIX_TREE\((\w*)/\2/v/' \
+ --regex-c='/DEFINE_PER_CPU\(([^,]*,\s*)(\w*).*\)/\2/v/' \
+ --regex-c='/DEFINE_PER_CPU_SHARED_ALIGNED\(([^,]*,\s*)(\w*).*\)/\2/v/' \
+ --regex-c='/DECLARE_WAIT_QUEUE_HEAD\((\w*)/\1/v/' \
+ --regex-c='/DECLARE_(TASKLET|WORK|DELAYED_WORK)\((\w*)/\2/v/' \
+ --regex-c='/DEFINE_PCI_DEVICE_TABLE\((\w*)/\1/v/'
all_kconfigs | xargs $1 -a \
--langdef=kconfig --language-force=kconfig \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [x86]: Compiler Option Os is better on latest x86
From: Ma Ling Currently we use O2 as compiler option for better performance, although it will enlarge code size, in modern CPUs larger instructon and unified cache, sophisticated instruction prefetch weaken instruction cache miss, meanwhile flags such as -falign-functions, -falign-jumps, -falign-loops, -falign-labels are very helpful to improve CPU front-end throughput because CPU fetch instruction by 16 alignedâbytes code block per cycle. In order to save power and get higher performance, Sandy Bridge starts to introduce decoded-cache, instructions will be kept in it after decode stage. When CPU refetches the instruction, decoded cache could provide 32 aligned-bytes instruction block, instead of 16 bytes from I-cache, fewer branch miss penalty resulted from shorter pipeline. It requires hot code should be put into decoded cache as possible we can. Sandy Bridge, Ivy Bridge, and Haswell all implemented this feature, Os-Optimize for size should be better than O2 on them. Based on above reasons, we compiled linux kernel 3.6.9 with O2 and Os respectively. The results show Os improve performance netperf 4.8%, 2.7% for volano as below O2 + netperf Performance counter stats for 'netperf' (3 runs): 5416.157986 task-clock#0.541 CPUs utilized ( +- 0.19% ) 348,249 context-switches #0.064 M/sec ( +- 0.17% ) 0 CPU-migrations#0.000 M/sec ( +- 0.00% ) 353 page-faults #0.000 M/sec ( +- 0.16% ) 13,166,254,384 cycles#2.431 GHz ( +- 0.18% ) 8,827,499,807 stalled-cycles-frontend # 67.05% frontend cycles idle ( +- 0.29% ) 5,951,234,060 stalled-cycles-backend# 45.20% backend cycles idle ( +- 0.44% ) 8,122,481,914 instructions #0.62 insns per cycle #1.09 stalled cycles per insn ( +- 0.17% ) 1,415,864,138 branches # 261.415 M/sec ( +- 0.17% ) 16,975,308 branch-misses #1.20% of all branches ( +- 0.61% ) 10.007215371 seconds time elapsed ( +- 0.03% ) Os + netperf Performance counter stats for 'netperf' (3 runs): 5395.386704 task-clock#0.539 CPUs utilized ( +- 0.14% ) 345,880 context-switches #0.064 M/sec ( +- 0.25% ) 0 CPU-migrations#0.000 M/sec ( +- 0.00% ) 354 page-faults #0.000 M/sec ( +- 0.00% ) 13,142,706,297 cycles#2.436 GHz ( +- 0.23% ) 8,379,382,641 stalled-cycles-frontend # 63.76% frontend cycles idle ( +- 0.50% ) 5,513,722,219 stalled-cycles-backend# 41.95% backend cycles idle ( +- 0.71% ) 8,554,202,795 instructions #0.65 insns per cycle #0.98 stalled cycles per insn ( +- 0.25% ) 1,530,020,505 branches # 283.579 M/sec ( +- 0.25% ) 17,710,406 branch-misses #1.16% of all branches ( +- 1.00% ) 10.004859867 seconds time elapsed During the same time (10.004859867 seconds) IPC from Os is 0.65, O2 is 0.62, Os improved performance 4.8% O2 + volano Performance counter stats for './loopclient.sh openjdk' (3 runs): 210627.115313 task-clock#0.781 CPUs utilized ( +- 0.92% ) 13,812,610 context-switches #0.066 M/sec ( +- 0.17% ) 2,352,755 CPU-migrations#0.011 M/sec ( +- 0.84% ) 208,333 page-faults #0.001 M/sec ( +- 1.58% ) 525,627,073,405 cycles#2.496 GHz ( +- 0.96% ) 428,177,571,365 stalled-cycles-frontend # 81.46% frontend cycles idle ( +- 1.09% ) 370,885,224,739 stalled-cycles-backend# 70.56% backend cycles idle ( +- 1.18% ) 187,662,577,544 instructions #0.36 insns per cycle #2.28 stalled cycles per insn ( +- 0.31% ) 35,684,976,425 branches # 169.423 M/sec ( +- 0.45% ) 1,062,086,942 branch-misses #2.98% of all branches ( +- 0.08% ) 269.764578435 seconds time elapsed Os + volano Performance counter stats for './loopclient.sh openjdk' (3 runs): 209545.786941 task-clock#0.778 CPUs utilized ( +- 0.66% ) 13,864,142 context-switches
Re: [PATCH] fbcon: fix locking harder
On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie wrote: > Okay so Alan's patch handled the case where there was no registered fbcon, > however the other path entered in set_con2fb_map pit. > > In there we called fbcon_takeover, but we also took the console lock in a > couple > of places. So push the console lock out to the callers of set_con2fb_map, > > this means fbmem and switcheroo needed to take the lock around the fb notifier > entry points that lead to this. > > This should fix the efifb regression seen by Maarten. > > Signed-off-by: Dave Airlie Linus might not be taking this for 3.8 because of lack of testing, but that doesn't mean the problems don't exist in 3.8 (and older). Maybe throw a CC for stable on the patch? That way it works its way back when it does get merged. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH Resend 1/3] sched: fix nr_busy_cpus with coupled cpuidle
2013/1/25 Vincent Guittot : > > Le 25 janv. 2013 13:00, "Frederic Weisbecker" a écrit : > > >> >> 2013/1/25 Vincent Guittot : >> > This sequence is not the right one >> > >> >> I'm going to look for the saved trace to check the sequence above >> > >> > I haven't been able to reproduce the bug that this patch was supposed to >> > solved. The patch 2 and 3 seem enough to fix the nr_busy_cpus field. I >> > will >> > continue to try to reproduce it but it seems that it was a side effect >> > of >> > the 2 others fixes of the series >> >> Ok. I just checked again as well and I can't find a scenario where >> this can happen. If you find it out or trigger the bug again, don't >> hesitate to resend this patch. > > Ok. I'm going to update the patch serie without this patch Actually your second patch may cause this, as it clears the NOHZ_IDLE flag on CPUs that are idle on boot and which could stay that way for a while. And your second patch is spotting something serious. I'll reply on it after more thoughts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] userns: improve uid/gid map collision detection
On Thu, Jan 24, 2013 at 04:46:12PM -0800, Andrew Morton wrote:
> eek, a macro! Macros are always bad.
>
> This one is bad because
>
> a) it's a macro
>
> b) it evaluates its args multiple times and hence will cause nasty
>bugs if called with expressions-with-side-effects.
>
> c) it evaluates its args multiple times and if called with
>non-trivial expressions the compiler might not be able to CSE those
>expressions, leading to code bloat.
>
> Add lo, this patch:
>
> ---
> a/kernel/user_namespace.c~userns-improve-uid-gid-map-collision-detection-fix
> +++ a/kernel/user_namespace.c
> @@ -521,7 +521,11 @@ struct seq_operations proc_projid_seq_op
>
> static DEFINE_MUTEX(id_map_mutex);
>
> -#define in_range(b,first,len) ((b)>=(first)&&(b)<(first)+(len))
> +static bool in_range(u32 b, u32 first, u32 len)
> +{
> + return b >= first && b < first + len;
> +}
> +
> static inline int extent_collision(struct uid_gid_map *new_map,
> struct uid_gid_extent *extent)
> {
>
> reduces the user_namespace.o text from 4822 bytes to 4727 with
> gcc-4.4.4. This is a remarkably large difference.
thanks Andrew
(I see Eric already answered about the config option)
--
Aristeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpiolib-acpi: Add ACPI5 event model support to gpio.
On 01/25/2013 02:54 PM, Linus Walleij wrote: On Fri, Jan 25, 2013 at 12:48 PM, Mathias Nyman wrote: Add ability to handle ACPI events signalled by GPIO interrupts. ACPI5 platforms can use GPIO signaled ACPI events. These GPIO interrupts are handled by ACPI event methods which need to be called from the GPIO controller's interrupt handler. acpi_gpio_request_interrupt() finds out which gpio pins have acpi event methods and assigns interrupt handlers that calls the acpi event methods for those pins. Partially based on work by Rui Zhang Signed-off-by: Mathias Nyman (...) +/** + * acpi_gpio_request_interrupt() - Register isr for gpio controller ACPI events + * @chip: gpio chip representation of the gpio controller Hm chip, controller, controller, chip chip, controller controller... Are we using two different names for the same thing? They get mixed up a bit here yes. I'll change them all to chip. + * + * ACPI5 platforms can use GPIO signaled ACPI events. These GPIO interrupts are + * handled by ACPI event methods which need to be called from the GPIO + * controller's interrupt handler. acpi_gpio_request_interrupt finds out which + * gpio pins have acpi event methods and assigns interrupt handlers that calls + * the acpi event methods for those pins. + */ + +void acpi_gpio_request_interrupt(struct gpio_chip *chip) So I was like "um, what acpi requests an interrupt for a GPIO (maybe a pin)... ... read read ... Aha the function should probably be named: acpi_gpiochip_request_interrupts() True, will rename it. Because it just grabs all IRQs coming from that chip right? Not all, only the ones that have an ACPI handler method defined. Basically ACPI5 supports using some of the gpio interrupts for the same purpose as SCI interrupts. Second: why is there no mirror function *releasing* all the IRQs again? One-way interface? My thinking was that using devm_request_threaded_irq(chip->dev, ...) will automatically free the interrupts on driver detach, making the release function unnecessary. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
On Fri, Jan 25, Jan Beulich wrote: > >>> On 24.01.13 at 19:59, Olaf Hering wrote: > > On Thu, Jan 24, KY Srinivasan wrote: > > > > > >> > Question is - considering you stated that this is supported > >> > starting in Win8, doesn't Hyper-V itself announce that > >> > capability in some explicit way? > >> > >> Thanks Jan. Unfortunately I don't think tis interrupt delivery model > >> is specified via a "feature" bit (I will check with the Windows guys). > >> Perhaps, we can have a Hyper-V specific compilation switch to address > >> the Xen emulation issue. > > > > Would that really help if both pvops XEN_PVHVM and HYPERV are enabled in > > the config? I assume at this point the access to the DMI data is not yet > > possible. > > As just said in another reply - with XEN_PVHVM, there's no problem, > since Xen gets checked for first. There's only a problem when > !XEN_PVHVM, because in that case Hyper-V will be probed for. > And the problem can only get bigger when on top of that the > out-of-tree PV drivers are intended to be used. Yes, xen_cpuid_base() recognizes Xen as hypervisor even with 'viridian=1' in the .cfg file. I think if there is no feature bit for this, the DMI can be used because its appearently available before the host is checked: ... [0.00] NX (Execute Disable) protection: active [0.00] DMI 2.4 present. [0.00] DMI: Xen HVM domU, BIOS 4.1.3_06-0.7.1 12/05/2012 [0.00] Hypervisor detected: Microsoft HyperV [0.00] HyperV: features 0x70, hints 0x0 [0.00] e820 update range: - 0001 (usable) ==> (reserved) ... Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lttng-dev] [PATCH] Add ACCESS_ONCE() to avoid compiler splitting assignments
On Sun, Jan 20, 2013 at 03:51:31PM -0500, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > On Wed, Jan 16, 2013 at 07:50:54AM -0500, Mathieu Desnoyers wrote:
> > > * Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote:
> > > > * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > > > > As noted by Konstantin Khlebnikov, gcc can split assignment of
> > > > > constants to long variables (https://lkml.org/lkml/2013/1/15/141),
> > > > > though assignment of NULL (0) is OK. Assuming that a gcc bug is
> > > > > fixed (http://gcc.gnu.org/bugzilla/attachment.cgi?id=29169=diff
> > > > > has a patch), making the store be volatile keeps gcc from splitting.
> > > > >
> > > > > This commit therefore applies ACCESS_ONCE() to CMM_STORE_SHARED(),
> > > > > which is the underlying primitive used by rcu_assign_pointer().
> > > >
> > > > Hi Paul,
> > > >
> > > > I recognise that this is an issue in the Linux kernel, since a simple
> > > > store is used and expected to be performed atomically when aligned.
> > > > However, I think this does not affect liburcu, see below:
> > >
> > > Side question: what gcc versions may issue non-atomic volatile stores ?
> > > I think we should at least document those. Bug
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 seems to target gcc
> > > 4.7.2, but I wonder when this issue first appeared on x86 and x86-64
> > > (and if it affects other architectures as well).
> >
> > I have no idea which versions are affected. The bug is in the x86
> > backend, so is specific to x86, but there might well be similar bugs
> > in other architectures.
>
> Results for my quick tests so far:
>
> gcc version 4.4.7 (Debian 4.4.7-2)
> gcc version 4.6.3 (Debian 4.6.3-11)
> gcc version 4.7.2 (Debian 4.7.2-5)
>
> for x86-64 are affected (all gcc installed currently on my Debian
> laptop). I made a simpler test case than the one shown on the bugzilla,
> which triggers the issue with -O0 and -O1 (-O2 and -Os optimisations
> seems not to show this issue with the simpler test case). So far, it
> seems to only affect stores from immediate value operands (and only some
> patterns).
Good to know! And more widespread than I would have guessed...
For whatever it is worth, there is an alleged patch here:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01119.html
> Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
> is not affected for x86-64.
Heh! Good to know as well. ;-)
Thanx, Paul
> My test case looks like this:
>
> * non-atomic-pointer.c:
>
> volatile void *var;
>
> void fct(void)
> {
> asm volatile ("/* test_begin */" : : : "memory");
> var = (void *) 0x10002;
> var = (void *) 0x30004;
> asm volatile ("/* test_end */" : : : "memory");
> }
>
>
> * build.sh:
>
> #!/bin/bash
>
> FLAGS="-S ${*}"
>
> function do_build
> {
> $1 ${FLAGS} -o non-atomic-pointer-$1.S.output non-atomic-pointer.c
> }
>
> do_build gcc-4.4
> do_build gcc-4.6
> do_build gcc-4.7
> do_build gcc-4.7
> do_build g++-4.6
> do_build g++-4.7
> do_build clang
>
>
> * check.py (might need adaptation for each architecture and O2, Os):
>
> #!/usr/bin/env python
>
> import sys, string, os, re
>
> # count the number of lines with "mov*" instructions between test_begin
> # and test_end. Should be 2. Report error if not.
>
> f = open (sys.argv[1], "r")
>
> lines = f.readlines()
>
> within_range = 0
> mov_count = 0
> error = 0
>
> re_mov = re.compile(' mov.*')
> re_begin = re.compile('.*test_begin.*')
> re_end = re.compile('.*test_end.*')
>
> output = ""
>
> for line in lines:
> if re_begin.match(line):
> within_range = 1
> elif re_end.match(line):
> within_range = 0
> elif (within_range and re_mov.match(line)):
> output += line
> mov_count += 1
>
> if mov_count > 2:
> error = 1
>
> f.close()
>
> if error > 0:
> print "[Error] expect 2 mov, found " + str(mov_count)
> print output
> 1
> else:
> 0
>
> >
> > > Thanks,
> > >
> > > Mathieu
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Paul E. McKenney
> > > > >
> > > > > diff --git a/urcu/system.h b/urcu/system.h
> > > > > index 2a45f22..7a1887e 100644
> > > > > --- a/urcu/system.h
> > > > > +++ b/urcu/system.h
> > > > > @@ -49,7 +49,7 @@
> > > > > */
> > > > > #define CMM_STORE_SHARED(x, v) \
> > > > > ({ \
> > > > > - __typeof__(x) _v = _CMM_STORE_SHARED(x, v); \
> > > > > + __typeof__(x) CMM_ACCESS_ONCE(_v) =
> > > > > _CMM_STORE_SHARED(x, v);\
> > > >
> > > > Here, the macro "_CMM_STORE_SHARED(x, v)" is doing the actual store.
> > > > It stores v into "x". So adding a CMM_ACCESS_ONCE(_v), as you propose
> > > > here, is really only making sure the return value (usually unused),
> > > > located
Re: [PATCH v2 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
On 01/25/2013 02:44 PM, Florian Vaussard wrote:
> Call to led_pwm_set() can happen inside atomic context, like triggers.
> If the PWM call can sleep, defer using a worker.
>
> Signed-off-by: Florian Vaussard
Reviewed-by: Peter Ujfalusi
> ---
> drivers/leds/leds-pwm.c | 50 +++---
> 1 files changed, 42 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index a1ea5f6..70effa7 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -23,12 +23,16 @@
> #include
> #include
> #include
> +#include
>
> struct led_pwm_data {
> struct led_classdev cdev;
> struct pwm_device *pwm;
> + struct work_struct work;
> unsigned intactive_low;
> unsigned intperiod;
> + int duty;
> + unsignedcan_sleep:1;
> };
>
> struct led_pwm_priv {
> @@ -36,6 +40,26 @@ struct led_pwm_priv {
> struct led_pwm_data leds[0];
> };
>
> +static void __led_pwm_set(struct led_pwm_data *led_dat)
> +{
> + int new_duty = led_dat->duty;
> +
> + pwm_config(led_dat->pwm, new_duty, led_dat->period);
> +
> + if (new_duty == 0)
> + pwm_disable(led_dat->pwm);
> + else
> + pwm_enable(led_dat->pwm);
> +}
> +
> +static void led_pwm_work(struct work_struct *work)
> +{
> + struct led_pwm_data *led_dat =
> + container_of(work, struct led_pwm_data, work);
> +
> + __led_pwm_set(led_dat);
> +}
> +
> static void led_pwm_set(struct led_classdev *led_cdev,
> enum led_brightness brightness)
> {
> @@ -44,13 +68,12 @@ static void led_pwm_set(struct led_classdev *led_cdev,
> unsigned int max = led_dat->cdev.max_brightness;
> unsigned int period = led_dat->period;
>
> - if (brightness == 0) {
> - pwm_config(led_dat->pwm, 0, period);
> - pwm_disable(led_dat->pwm);
> - } else {
> - pwm_config(led_dat->pwm, brightness * period / max, period);
> - pwm_enable(led_dat->pwm);
> - }
> + led_dat->duty = brightness * period / max;
> +
> + if (led_dat->can_sleep)
> + schedule_work(_dat->work);
> + else
> + __led_pwm_set(led_dat);
> }
>
> static inline size_t sizeof_pwm_leds_priv(int num_leds)
> @@ -100,6 +123,10 @@ static struct led_pwm_priv *led_pwm_create_of(struct
> platform_device *pdev)
> led_dat->cdev.brightness = LED_OFF;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + led_dat->can_sleep = pwm_cansleep(led_dat->pwm);
> + if (led_dat->can_sleep)
> + INIT_WORK(_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(>dev, _dat->cdev);
> if (ret < 0) {
> dev_err(>dev, "failed to register for %s\n",
> @@ -153,6 +180,10 @@ static int led_pwm_probe(struct platform_device *pdev)
> led_dat->cdev.max_brightness = cur_led->max_brightness;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + led_dat->can_sleep = pwm_cansleep(led_dat->pwm);
> + if (led_dat->can_sleep)
> + INIT_WORK(_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(>dev, _dat->cdev);
> if (ret < 0)
> goto err;
> @@ -180,8 +211,11 @@ static int led_pwm_remove(struct platform_device *pdev)
> struct led_pwm_priv *priv = platform_get_drvdata(pdev);
> int i;
>
> - for (i = 0; i < priv->num_leds; i++)
> + for (i = 0; i < priv->num_leds; i++) {
> led_classdev_unregister(>leds[i].cdev);
> + if (priv->leds[i].can_sleep)
> + cancel_work_sync(>leds[i].work);
> + }
>
> return 0;
> }
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
On 01/25/2013 02:44 PM, Florian Vaussard wrote:
> Calls to some external PWM chips can sleep. To help users,
> add pwm_cansleep() API.
>
> Signed-off-by: Florian Vaussard
Reviewed-by: Peter Ujfalusi
> ---
> drivers/pwm/core.c | 12
> include/linux/pwm.h | 10 ++
> 2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 4a13da4..e737f5f 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -763,6 +763,18 @@ void devm_pwm_put(struct device *dev, struct pwm_device
> *pwm)
> }
> EXPORT_SYMBOL_GPL(devm_pwm_put);
>
> +/**
> + * pwm_cansleep() - report whether pwm access will sleep
> + * @pwm: PWM device
> + *
> + * It returns nonzero if accessing the PWM can sleep.
> + */
> +int pwm_cansleep(struct pwm_device *pwm)
> +{
> + return pwm->chip->can_sleep;
> +}
> +EXPORT_SYMBOL_GPL(pwm_cansleep);
> +
> #ifdef CONFIG_DEBUG_FS
> static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
> {
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 70655a2..e2cb5c7 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -146,6 +146,8 @@ struct pwm_ops {
> * @base: number of first PWM controlled by this chip
> * @npwm: number of PWMs controlled by this chip
> * @pwms: array of PWM devices allocated by the framework
> + * @can_sleep: flag must be set iff config()/enable()/disable() methods
> sleep,
> + * as they must while accessing PWM chips over I2C or SPI
> */
> struct pwm_chip {
> struct device *dev;
> @@ -159,6 +161,7 @@ struct pwm_chip {
> struct pwm_device * (*of_xlate)(struct pwm_chip *pc,
> const struct of_phandle_args *args);
> unsigned intof_pwm_n_cells;
> + unsigned intcan_sleep:1;
> };
>
> #if IS_ENABLED(CONFIG_PWM)
> @@ -182,6 +185,8 @@ struct pwm_device *devm_pwm_get(struct device *dev, const
> char *con_id);
> struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node
> *np,
> const char *con_id);
> void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
> +
> +int pwm_cansleep(struct pwm_device *pwm);
> #else
> static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data)
> {
> @@ -242,6 +247,11 @@ static inline struct pwm_device *devm_of_pwm_get(struct
> device *dev,
> static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
> {
> }
> +
> +static inline int pwm_cansleep(struct pwm_device *pwm)
> +{
> + return 0;
> +}
> #endif
>
> struct pwm_lookup {
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] pwm: Add can_sleep property to drivers
On 01/25/2013 02:44 PM, Florian Vaussard wrote: > Calls to PWM drivers connected through I2C can sleep. > Use the new can_sleep property. > > Signed-off-by: Florian Vaussard Acked-by: Peter Ujfalusi > --- > drivers/pwm/pwm-twl-led.c |1 + > drivers/pwm/pwm-twl.c |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c > index 9dfa0f3..6261193 100644 > --- a/drivers/pwm/pwm-twl-led.c > +++ b/drivers/pwm/pwm-twl-led.c > @@ -300,6 +300,7 @@ static int twl_pwmled_probe(struct platform_device *pdev) > > twl->chip.dev = >dev; > twl->chip.base = -1; > + twl->chip.can_sleep = 1; > > mutex_init(>mutex); > > diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c > index e65db95..4e56cd8 100644 > --- a/drivers/pwm/pwm-twl.c > +++ b/drivers/pwm/pwm-twl.c > @@ -315,6 +315,7 @@ static int twl_pwm_probe(struct platform_device *pdev) > twl->chip.dev = >dev; > twl->chip.base = -1; > twl->chip.npwm = 2; > + twl->chip.can_sleep = 1; > > mutex_init(>mutex); > > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Commit 607ca46e97a1b6594b29647d98a32d545c24bdff breaks building tools/hv/hv_kvp_daemon.c
2012/12/12 Bjarke Istrup Pedersen : > Hey, > > It seems like this commit breaks building hv_kvp_daemon. > > Here is the bisect log: > > # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6 > git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9 > # bad: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7 > git bisect bad 29594404d7fe73cd80eaa4ee8c43dcc53970c60e > # good: [d66e6737d454553e1e62109d8298ede5351178a4] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 > git bisect good d66e6737d454553e1e62109d8298ede5351178a4 > # good: [e1b28147f684af67bfac989756c27c19859d3d4e] Merge branch > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux > git bisect good e1b28147f684af67bfac989756c27c19859d3d4e > # bad: [37820108f395032e850e400139d956561a043c26] Merge tag > 'fixes-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > git bisect bad 37820108f395032e850e400139d956561a043c26 > # good: [4f1cd91497774488ed16119ec3f54b3daf1561de] Merge branch > 'v4l_for_linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > git bisect good 4f1cd91497774488ed16119ec3f54b3daf1561de > # good: [9db908806b85c1430150fbafe269a7b21b07d15d] Merge tag 'md-3.7' > of git://neil.brown.name/md > git bisect good 9db908806b85c1430150fbafe269a7b21b07d15d > # bad: [43c422eda99b894f18d1cca17bcd2401efaf7bd0] apparmor: fix > apparmor OOPS in audit_log_untrustedstring+0x1c/0x40 > git bisect bad 43c422eda99b894f18d1cca17bcd2401efaf7bd0 > # bad: [2384d6aa079de7c16c7877220d3cd4c6f4f50767] bnx2x: fix handling > mf storage modes > git bisect bad 2384d6aa079de7c16c7877220d3cd4c6f4f50767 > # good: [dbadc17683e6c673a69b236c0f041b931cc55c42] X.509: Fix > indefinite length element skip error handling > git bisect good dbadc17683e6c673a69b236c0f041b931cc55c42 > # good: [35bafbee4b4732a2820bbd0ef141c8192ff29731] Merge tag > 'disintegrate-mips-20121009' of > git://git.infradead.org/users/dhowells/linux-headers into > mips-for-linux-next > git bisect good 35bafbee4b4732a2820bbd0ef141c8192ff29731 > # bad: [0b381a286e5d748b1fd80095d3dd52326819742f] Merge tag > 'disintegrate-main-20121013' of > git://git.infradead.org/users/dhowells/linux-headers > git bisect bad 0b381a286e5d748b1fd80095d3dd52326819742f > # good: [7c5a47346989e43ba34a9c94a55cc0aef7ed6b3b] Merge tag > 'openrisc-uapi' of git://openrisc.net/jonas/linux > git bisect good 7c5a47346989e43ba34a9c94a55cc0aef7ed6b3b > # bad: [607ca46e97a1b6594b29647d98a32d545c24bdff] UAPI: (Scripted) > Disintegrate include/linux > git bisect bad 607ca46e97a1b6594b29647d98a32d545c24bdff > # good: [08cce05c5a91f5017f4edc9866cf026908c73f9f] UAPI: Unexport > linux/blk_types.h > git bisect good 08cce05c5a91f5017f4edc9866cf026908c73f9f > > Here is the build output from 3.7.0: > > hv # gcc hv_kvp_daemon.c -I/usr/src/linux/include -o hv_kvp_daemon > In file included from hv_kvp_daemon.c:29:0: > /usr/src/linux/include/linux/types.h:14:26: error: conflicting types > for ‘fd_set’ > /usr/include/sys/select.h:75:5: note: previous declaration of ‘fd_set’ was > here > /usr/src/linux/include/linux/types.h:15:25: error: conflicting types for > ‘dev_t’ > /usr/include/sys/types.h:60:17: note: previous declaration of ‘dev_t’ was here > /usr/src/linux/include/linux/types.h:17:26: error: conflicting types > for ‘mode_t’ > /usr/include/sys/types.h:70:18: note: previous declaration of ‘mode_t’ was > here > /usr/src/linux/include/linux/types.h:25:26: error: conflicting types > for ‘timer_t’ > /usr/include/time.h:103:19: note: previous declaration of ‘timer_t’ was here > /usr/src/linux/include/linux/types.h:134:23: error: conflicting types > for ‘blkcnt_t’ > /usr/include/sys/types.h:235:20: note: previous declaration of > ‘blkcnt_t’ was here > In file included from > /usr/lib/gcc/i586-pc-linux-gnu/4.6.3/include/stdint.h:3:0, > from /usr/include/netinet/in.h:23, > from /usr/include/arpa/inet.h:22, > from hv_kvp_daemon.c:36: > /usr/include/stdint.h:128:23: error: conflicting types for ‘uintptr_t’ > /usr/src/linux/include/linux/types.h:36:24: note: previous declaration > of ‘uintptr_t’ was here > In file included from /usr/src/linux/include/linux/connector.h:25:0, > from hv_kvp_daemon.c:37: > /usr/src/linux/include/linux/atomic.h:4:24: fatal error: asm/atomic.h: > No such file or directory > compilation terminated. > > Is there an easy fix for this, my server is complaining about I need > to upgrade hv_kvp_daemon for my 3.7.0 kernel. > > Best regards, > Bjarke Sorry for resending this, but it does still not work. Is there anything that can be done to fix this? Best regards, Bjarke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] panda board locks up on boot
On Fri, 2013-01-25 at 08:52 +, Russell King - ARM Linux wrote: > On Thu, Jan 24, 2013 at 10:01:26PM -0500, Steven Rostedt wrote: > > I've recently started testing my work on arm boards and have found that > > they both don't boot under the latest kernel anymore. I already posted > > about my snowball board, but my panda board also locks up. > > You need to enable DMA engine and the OMAP DMA engine driver. I believe > someone was going to work on adding PIO-mode support to the driver but > I suspect as TI's OMAP division is being reorganized, all that is now > uncertain. Well, I be darn... Yep, selecting DMA_OMAP which selects DMA_ENGINE makes everything better. Who'da thunk? Now only if there was a config option missing for my snowball? Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] lpc_ich: fix gpio base and control offsets
On Fri, 2013-01-25 at 10:47 +0100, Linus Walleij wrote:
> On Thu, Jan 24, 2013 at 9:52 PM, Aaron Sierra wrote:
>
> > In ICH5 and earlier the GPIOBASE and GPIOCTRL registers are found at
> > offsets 0x58 and 0x5C, respectively. This patch allows GPIO access to
> > properly be enabled (and disabled) for these chipsets.
> >
> > Signed-off-by: Agócs Pál
> > Signed-off-by: Aaron Sierra
>
> OK... Paul, can you test this on your setup?
>
> > @@ -858,14 +874,35 @@ wdt_done:
> > static int lpc_ich_probe(struct pci_dev *dev,
> > const struct pci_device_id *id)
> > {
> > + struct lpc_ich_priv *priv;
> > int ret;
> > bool cell_added = false;
> >
> > - ret = lpc_ich_init_wdt(dev, id);
> > + priv = kmalloc(GFP_KERNEL, sizeof(struct lpc_ich_priv));
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->chipset = id->driver_data;
>
> So where is this id->driver_data which is just assigned to
> priv->chipset coming from again? ACPI something?
That's how pci device probing works.
The driver defines a struct pci_device_id[] table with
DEFINE_PCI_DEVICE_TABLE(), initializing the .driver_data fields with an
index into a static array of device types (in this case, struct
lpc_ich_info lpc_chipset_info[]), and the pci subsystem passes the
actual matching pci_device_id* to the driver's probe() function.
There's more information in Documentation/pci.txt
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] pwm: Add can_sleep property to drivers
Calls to PWM drivers connected through I2C can sleep. Use the new can_sleep property. Signed-off-by: Florian Vaussard --- drivers/pwm/pwm-twl-led.c |1 + drivers/pwm/pwm-twl.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c index 9dfa0f3..6261193 100644 --- a/drivers/pwm/pwm-twl-led.c +++ b/drivers/pwm/pwm-twl-led.c @@ -300,6 +300,7 @@ static int twl_pwmled_probe(struct platform_device *pdev) twl->chip.dev = >dev; twl->chip.base = -1; + twl->chip.can_sleep = 1; mutex_init(>mutex); diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c index e65db95..4e56cd8 100644 --- a/drivers/pwm/pwm-twl.c +++ b/drivers/pwm/pwm-twl.c @@ -315,6 +315,7 @@ static int twl_pwm_probe(struct platform_device *pdev) twl->chip.dev = >dev; twl->chip.base = -1; twl->chip.npwm = 2; + twl->chip.can_sleep = 1; mutex_init(>mutex); -- 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 v2 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
Call to led_pwm_set() can happen inside atomic context, like triggers.
If the PWM call can sleep, defer using a worker.
Signed-off-by: Florian Vaussard
---
drivers/leds/leds-pwm.c | 50 +++---
1 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index a1ea5f6..70effa7 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -23,12 +23,16 @@
#include
#include
#include
+#include
struct led_pwm_data {
struct led_classdev cdev;
struct pwm_device *pwm;
+ struct work_struct work;
unsigned intactive_low;
unsigned intperiod;
+ int duty;
+ unsignedcan_sleep:1;
};
struct led_pwm_priv {
@@ -36,6 +40,26 @@ struct led_pwm_priv {
struct led_pwm_data leds[0];
};
+static void __led_pwm_set(struct led_pwm_data *led_dat)
+{
+ int new_duty = led_dat->duty;
+
+ pwm_config(led_dat->pwm, new_duty, led_dat->period);
+
+ if (new_duty == 0)
+ pwm_disable(led_dat->pwm);
+ else
+ pwm_enable(led_dat->pwm);
+}
+
+static void led_pwm_work(struct work_struct *work)
+{
+ struct led_pwm_data *led_dat =
+ container_of(work, struct led_pwm_data, work);
+
+ __led_pwm_set(led_dat);
+}
+
static void led_pwm_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -44,13 +68,12 @@ static void led_pwm_set(struct led_classdev *led_cdev,
unsigned int max = led_dat->cdev.max_brightness;
unsigned int period = led_dat->period;
- if (brightness == 0) {
- pwm_config(led_dat->pwm, 0, period);
- pwm_disable(led_dat->pwm);
- } else {
- pwm_config(led_dat->pwm, brightness * period / max, period);
- pwm_enable(led_dat->pwm);
- }
+ led_dat->duty = brightness * period / max;
+
+ if (led_dat->can_sleep)
+ schedule_work(_dat->work);
+ else
+ __led_pwm_set(led_dat);
}
static inline size_t sizeof_pwm_leds_priv(int num_leds)
@@ -100,6 +123,10 @@ static struct led_pwm_priv *led_pwm_create_of(struct
platform_device *pdev)
led_dat->cdev.brightness = LED_OFF;
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
+ led_dat->can_sleep = pwm_cansleep(led_dat->pwm);
+ if (led_dat->can_sleep)
+ INIT_WORK(_dat->work, led_pwm_work);
+
ret = led_classdev_register(>dev, _dat->cdev);
if (ret < 0) {
dev_err(>dev, "failed to register for %s\n",
@@ -153,6 +180,10 @@ static int led_pwm_probe(struct platform_device *pdev)
led_dat->cdev.max_brightness = cur_led->max_brightness;
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
+ led_dat->can_sleep = pwm_cansleep(led_dat->pwm);
+ if (led_dat->can_sleep)
+ INIT_WORK(_dat->work, led_pwm_work);
+
ret = led_classdev_register(>dev, _dat->cdev);
if (ret < 0)
goto err;
@@ -180,8 +211,11 @@ static int led_pwm_remove(struct platform_device *pdev)
struct led_pwm_priv *priv = platform_get_drvdata(pdev);
int i;
- for (i = 0; i < priv->num_leds; i++)
+ for (i = 0; i < priv->num_leds; i++) {
led_classdev_unregister(>leds[i].cdev);
+ if (priv->leds[i].can_sleep)
+ cancel_work_sync(>leds[i].work);
+ }
return 0;
}
--
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 v2 0/3] leds-pwm: Defer PWM calls if PWM can sleep
Hello, When using the leds-pwm module with external PWM chips connected through I2C, the kernel will panic when settings a trigger. In this case, PWM calls can sleep, and should be deferred. Patch 1 and 2 add the necessary API to the PWM subsystem, and update matching drivers. Patch 3 updates leds-pwm to use a worker if the PWM chip can sleep, or performs direct calls otherwise. This patchset is based on the for-next branch of the led subsystem [1], as patch 3 depends on the recent work of Peter for DT bindings in leds-pwm. The pwm patches should probably follow the same path. Tested on Overo (OMAP3 + TWL4030) with device tree. Best regards, Florian [1] git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git Changes from v1: * pwm_can_sleep -> pwm_cansleep * avoid duplicated code between the worker and the direct call * cache the value of pwm_cansleep inside leds-pwm to avoid API calls Florian Vaussard (3): pwm: Add pwm_cansleep() as exported API to users pwm: Add can_sleep property to drivers leds: leds-pwm: Defer led_pwm_set() if PWM can sleep drivers/leds/leds-pwm.c | 50 +--- drivers/pwm/core.c| 12 ++ drivers/pwm/pwm-twl-led.c |1 + drivers/pwm/pwm-twl.c |1 + include/linux/pwm.h | 10 + 5 files changed, 66 insertions(+), 8 deletions(-) -- 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 v2 1/3] pwm: Add pwm_cansleep() as exported API to users
Calls to some external PWM chips can sleep. To help users,
add pwm_cansleep() API.
Signed-off-by: Florian Vaussard
---
drivers/pwm/core.c | 12
include/linux/pwm.h | 10 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 4a13da4..e737f5f 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -763,6 +763,18 @@ void devm_pwm_put(struct device *dev, struct pwm_device
*pwm)
}
EXPORT_SYMBOL_GPL(devm_pwm_put);
+/**
+ * pwm_cansleep() - report whether pwm access will sleep
+ * @pwm: PWM device
+ *
+ * It returns nonzero if accessing the PWM can sleep.
+ */
+int pwm_cansleep(struct pwm_device *pwm)
+{
+ return pwm->chip->can_sleep;
+}
+EXPORT_SYMBOL_GPL(pwm_cansleep);
+
#ifdef CONFIG_DEBUG_FS
static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
{
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 70655a2..e2cb5c7 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -146,6 +146,8 @@ struct pwm_ops {
* @base: number of first PWM controlled by this chip
* @npwm: number of PWMs controlled by this chip
* @pwms: array of PWM devices allocated by the framework
+ * @can_sleep: flag must be set iff config()/enable()/disable() methods sleep,
+ * as they must while accessing PWM chips over I2C or SPI
*/
struct pwm_chip {
struct device *dev;
@@ -159,6 +161,7 @@ struct pwm_chip {
struct pwm_device * (*of_xlate)(struct pwm_chip *pc,
const struct of_phandle_args *args);
unsigned intof_pwm_n_cells;
+ unsigned intcan_sleep:1;
};
#if IS_ENABLED(CONFIG_PWM)
@@ -182,6 +185,8 @@ struct pwm_device *devm_pwm_get(struct device *dev, const
char *con_id);
struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
const char *con_id);
void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
+
+int pwm_cansleep(struct pwm_device *pwm);
#else
static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data)
{
@@ -242,6 +247,11 @@ static inline struct pwm_device *devm_of_pwm_get(struct
device *dev,
static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
{
}
+
+static inline int pwm_cansleep(struct pwm_device *pwm)
+{
+ return 0;
+}
#endif
struct pwm_lookup {
--
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/
Re: [PATCH v3] lpc_ich: fix gpio base and control offsets
On Fri, 2013-01-25 at 14:25 +0100, Paul Bolle wrote: > 0) insmod-ing an updated lpc_ich.ko generated quite a bit of noise in > dmesg: > <6>[19913.247530] iTCO_wdt: Found a ICH8M-E TCO device (Version=2, > TCOBASE=0x1060) > <6>[19913.249310] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) > <4>[19913.249332] ACPI Warning: 0x1028-0x102f > SystemIO conflicts with Region \_SB_.PCI0.LPC_.PMIO 1 (20120913/utaddress-251) > <6>[19913.249338] ACPI: If an ACPI driver is available for this device, > you should use it instead of the native driver > <4>[19913.249342] ACPI Warning: 0x11b0-0x11bf > SystemIO conflicts with Region \_SB_.PCI0.LPC_.LPIO 1 (20120913/utaddress-251) > <6>[19913.249347] ACPI: If an ACPI driver is available for this device, > you should use it instead of the native driver > <4>[19913.249349] ACPI Warning: 0x1180-0x11af > SystemIO conflicts with Region \_SB_.PCI0.LPC_.LPIO 1 (20120913/utaddress-251) > <6>[19913.249353] ACPI: If an ACPI driver is available for this device, > you should use it instead of the native driver > <4>[19913.249355] lpc_ich: Resource conflict(s) found affecting gpio_ich > > I have no idea whatsoever what that could mean. But please note that these messages are nothing new. I found identical messages in all my logs (from v3.7.y kernels; I do not seem to have logs of older releases anymore). Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Hyper-V: register clocksource only if its advertised
Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.
Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter. Register the clocksource only if this bit is set.
The guest in question prints this in dmesg:
[0.00] Hypervisor detected: Microsoft HyperV
[0.00] HyperV: features 0x70, hints 0x0
This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with
'clocksource=jiffies'.
Signed-off-by: Olaf Hering
Cc: sta...@kernel.org
Cc: KY Srinivasan
Cc: Greg KH
---
arch/x86/kernel/cpu/mshyperv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 0a630dd..646d192 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -68,7 +68,8 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
ms_hyperv.features, ms_hyperv.hints);
- clocksource_register_hz(_cs, NSEC_PER_SEC/100);
+ if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
+ clocksource_register_hz(_cs, NSEC_PER_SEC/100);
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
On 01/25/2013 04:33 AM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, new API's
> for adding PHY and getting PHY has been added. Now the binding
> information for the PHY and controller should be done in platform file
> using usb_bind_phy API. And for getting a PHY, the device pointer of the
> USB controller and an index should be passed. Based on the binding
> information that is added in the platform file, usb_get_phy_dev will return
> the
> appropriate PHY.
> Already existing API's to add and get phy by type is not removed. These
> API's are deprecated and will be removed once all the platforms start to
> use the new API.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/otg/otg.c | 118
> ++-
> include/linux/usb/phy.h | 13 ++
> 2 files changed, 130 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index 8e756d9..4bb4333 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -36,6 +36,24 @@ static struct usb_phy *__usb_find_phy(struct list_head
> *list,
> return ERR_PTR(-ENODEV);
> }
>
> +static struct usb_phy *__usb_find_phy_dev(struct device *dev,
> + struct list_head *list, u8 index)
> +{
> + struct usb_phy_bind *phy_bind = NULL;
> +
> + list_for_each_entry(phy_bind, list, list) {
> + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
> + phy_bind->index == index) {
> + if (phy_bind->phy)
> + return phy_bind->phy;
> + else
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
> static void devm_usb_phy_release(struct device *dev, void *res)
> {
> struct usb_phy *phy = *(struct usb_phy **)res;
> @@ -112,6 +130,69 @@ err0:
> EXPORT_SYMBOL(usb_get_phy);
>
> /**
> + * usb_get_phy_dev - find the USB PHY
> + * @dev - device that requests this phy
> + * @index - the index of the phy
> + *
> + * Returns the phy driver, after getting a refcount to it; or
PHY driver or PHY device?
> + * -ENODEV if there is no such phy. The caller is responsible for
> + * calling usb_put_phy() to release that count.
> + *
> + * For use by USB host and peripheral drivers.
> + */
> +struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
> +{
> + struct usb_phy *phy = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_lock, flags);
> +
> + phy = __usb_find_phy_dev(dev, _bind_list, index);
> + if (IS_ERR(phy)) {
> + pr_err("unable to find transceiver\n");
I would suggest not to print and leave it to the user. This print
"unable to find transceiver" gives no valuable information/context.
Also -EPROBE_DEFER is a valid case where this message must not be printed.
> + goto err0;
> + }
> +
> + get_device(phy->dev);
> +
> +err0:
> + spin_unlock_irqrestore(_lock, flags);
> +
> + return phy;
> +}
> +EXPORT_SYMBOL(usb_get_phy_dev);
> +
> +/**
> + * devm_usb_get_phy_dev - find the USB PHY using device ptr and index
> + * @dev - device that requests this phy
> + * @index - the index of the phy
> + *
> + * Gets the phy using usb_get_phy_dev(), and associates a device with it
> using
> + * devres. On driver detach, release function is invoked on the devres data,
> + * then, devres data is freed.
> + *
> + * For use by USB host and peripheral drivers.
> + */
> +struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
> +{
> + struct usb_phy **ptr, *phy;
> +
> + ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + phy = usb_get_phy_dev(dev, index);
> + if (!IS_ERR(phy)) {
> + *ptr = phy;
> + devres_add(dev, ptr);
> + } else
> + devres_free(ptr);
> +
> + return phy;
> +}
> +EXPORT_SYMBOL(devm_usb_get_phy_dev);
> +
> +/**
> * devm_usb_put_phy - release the USB PHY
> * @dev - device that wants to release this phy
> * @phy - the phy returned by devm_usb_get_phy()
> @@ -186,6 +267,36 @@ out:
> EXPORT_SYMBOL(usb_add_phy);
>
> /**
> + * usb_add_phy_dev - declare the USB PHY
> + * @x: the USB phy to be used; or NULL
@phy is better than @x?
> + *
> + * This call is exclusively for use by phy drivers, which
> + * coordinate the activities of drivers for host and peripheral
> + * controllers, and in some cases for VBUS current regulation.
> + */
> +int usb_add_phy_dev(struct usb_phy *x)
> +{
> + struct usb_phy_bind *phy_bind;
> + unsigned long flags;
> +
> + if (!x->dev) {
> + dev_err(x->dev, "no device provided for PHY\n");
> + return -EINVAL;
> + }
> +
> + spin_lock_irqsave(_lock, flags);
> + list_for_each_entry(phy_bind, _bind_list, list)
> + if
Re: [PATCH 3/3] aio-use-cancellation-list-lazily-fix
On Fri, Jan 25, 2013 at 5:43 AM, Kent Overstreet wrote:
> The cancellation changes were fubar - we can't cancel a kiocb if it
> doesn't actually have a cancellation callback.
>
> The use of xchg() in aio_complete() was right - there we're marking the
> kiocb as completed - but we need to use cmpxchg() in kiocb_cancel() - a
> lock isn't sufficient since we're synchronizing with aio_complete()
> which isn't taking any locks.
>
What is observed without this fix?
> Signed-off-by: Kent Overstreet
> ---
> fs/aio.c| 32 ++--
> include/linux/aio.h | 11 +++
> 2 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/fs/aio.c b/fs/aio.c
> index 85d1b38..2760180 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -244,28 +244,40 @@ static int aio_setup_ring(struct kioctx *ctx)
>
> void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn *cancel)
> {
> - if (!req->ki_list.next) {
> - struct kioctx *ctx = req->ki_ctx;
> - unsigned long flags;
> + struct kioctx *ctx = req->ki_ctx;
> + unsigned long flags;
>
> - spin_lock_irqsave(>ctx_lock, flags);
> + spin_lock_irqsave(>ctx_lock, flags);
> +
> + if (!req->ki_list.next)
> list_add(>ki_list, >active_reqs);
> - spin_unlock_irqrestore(>ctx_lock, flags);
> - }
>
> req->ki_cancel = cancel;
> +
> + spin_unlock_irqrestore(>ctx_lock, flags);
> }
> EXPORT_SYMBOL(kiocb_set_cancel_fn);
>
> static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb,
> struct io_event *res)
> {
> - kiocb_cancel_fn *cancel;
> + kiocb_cancel_fn *old, *cancel;
> int ret = -EINVAL;
>
> - cancel = xchg(>ki_cancel, KIOCB_CANCELLED);
> - if (!cancel || cancel == KIOCB_CANCELLED)
> - return ret;
> + /*
> +* Don't want to set kiocb->ki_cancel = KIOCB_CANCELLED unless it
> +* actually has a cancel function, hence the cmpxchg()
> +*/
> +
> + cancel = ACCESS_ONCE(kiocb->ki_cancel);
> + do {
> + if (!cancel || cancel == KIOCB_CANCELLED)
> + return ret;
> +
> + BUG();
Hmm, what is trapped?
> + old = cancel;
> + cancel = cmpxchg(>ki_cancel, old, KIOCB_CANCELLED);
> + } while (cancel != old);
>
> atomic_inc(>ki_users);
> spin_unlock_irq(>ctx_lock);
> diff --git a/include/linux/aio.h b/include/linux/aio.h
> index 8eaa490..cd4aea0 100644
> --- a/include/linux/aio.h
> +++ b/include/linux/aio.h
> @@ -15,6 +15,17 @@ struct batch_complete;
>
> #define KIOCB_KEY 0
>
> +/*
> + * We use ki_cancel == KIOCB_CANCELLED to indicate that a kiocb has been
> either
> + * cancelled or completed (this makes a certain amount of sense because
> + * successful cancellation - io_cancel() - does deliver the completion to
> + * userspace).
> + *
> + * And since most things don't implement kiocb cancellation and we'd really
> like
> + * kiocb completion to be lockless when possible, we use ki_cancel to
> + * synchronize cancellation and completion - we only set it to
> KIOCB_CANCELLED
> + * with xchg() or cmpxchg(), see batch_complete_aio() and kiocb_cancel().
> + */
> #define KIOCB_CANCELLED((void *) (~0ULL))
>
> typedef int (kiocb_cancel_fn)(struct kiocb *, struct io_event *);
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: tps80031: Use IS_ERR to check return value of regulator_register()
regulator_register() does not return NULL, it returns ERR_PTR on error.
Signed-off-by: Axel Lin
---
drivers/regulator/tps80031-regulator.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps80031-regulator.c
b/drivers/regulator/tps80031-regulator.c
index b15d711..9019d0e 100644
--- a/drivers/regulator/tps80031-regulator.c
+++ b/drivers/regulator/tps80031-regulator.c
@@ -728,7 +728,7 @@ static int tps80031_regulator_probe(struct platform_device
*pdev)
}
}
rdev = regulator_register(>rinfo->desc, );
- if (IS_ERR_OR_NULL(rdev)) {
+ if (IS_ERR(rdev)) {
dev_err(>dev,
"register regulator failed %s\n",
ri->rinfo->desc.name);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] lpc_ich: fix gpio base and control offsets
On Fri, 2013-01-25 at 13:43 +0100, Linus Walleij wrote: > On Fri, Jan 25, 2013 at 1:00 PM, Paul Bolle wrote: > > Would testing on 3.7.5 be helpful? > > Sure it's as good an indicator of the quality of the patch as any. > > If it works on that kernel, it makes probablility lower that it breaks > your machine later on atleast. 0) insmod-ing an updated lpc_ich.ko generated quite a bit of noise in dmesg: <6>[19913.247530] iTCO_wdt: Found a ICH8M-E TCO device (Version=2, TCOBASE=0x1060) <6>[19913.249310] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) <4>[19913.249332] ACPI Warning: 0x1028-0x102f SystemIO conflicts with Region \_SB_.PCI0.LPC_.PMIO 1 (20120913/utaddress-251) <6>[19913.249338] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver <4>[19913.249342] ACPI Warning: 0x11b0-0x11bf SystemIO conflicts with Region \_SB_.PCI0.LPC_.LPIO 1 (20120913/utaddress-251) <6>[19913.249347] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver <4>[19913.249349] ACPI Warning: 0x1180-0x11af SystemIO conflicts with Region \_SB_.PCI0.LPC_.LPIO 1 (20120913/utaddress-251) <6>[19913.249353] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver <4>[19913.249355] lpc_ich: Resource conflict(s) found affecting gpio_ich I have no idea whatsoever what that could mean. 1) Should I try booting with the updated module too? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] usb: otg: Add an API to bind the USB controller and PHY
On 01/25/2013 04:33 AM, Kishon Vijay Abraham I wrote:
> In order to support platforms which has multiple PHY's (of same type) and
> which has multiple USB controllers, a new design is adopted wherin the binding
> information (between the PHY and the USB controller) should be passed to the
> PHY library from platform specific file (board file).
> So added a new API to pass the binding information.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/otg/otg.c | 37 +
> include/linux/usb/phy.h | 22 ++
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index a30c041..8e756d9 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -18,6 +18,7 @@
> #include
>
> static LIST_HEAD(phy_list);
> +static LIST_HEAD(phy_bind_list);
> static DEFINE_SPINLOCK(phy_lock);
>
> static struct usb_phy *__usb_find_phy(struct list_head *list,
> @@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
> }
> EXPORT_SYMBOL(usb_remove_phy);
>
> +/**
> + * usb_bind_phy - bind the phy and the controller that uses the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @index: index to specify the port number
> + * @phy_dev_name: the device name of the phy
> + *
> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
> + * be used when the phy driver registers the phy and when the controller
> + * requests this phy.
> + *
> + * To be used by platform specific initialization code.
> + */
> +int __init usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name)
> +{
> + struct usb_phy_bind *phy_bind;
> + unsigned long flags;
> +
> + phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
> + if (!phy_bind) {
> + pr_err("phy_bind(): No memory for phy_bind");
nitpick. Function name is usb_bind_phy() and you don't need to mention it twice
;).
Is it even needed to print here as the user would most likely print it anyways.
At least
the user can decide if it needs to be printed or not.
> + return -ENOMEM;
> + }
> +
> + phy_bind->dev_name = dev_name;
> + phy_bind->phy_dev_name = phy_dev_name;
> + phy_bind->index = index;
> +
> + spin_lock_irqsave(_lock, flags);
> + list_add_tail(_bind->list, _bind_list);
> + spin_unlock_irqrestore(_lock, flags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_bind_phy);
> +
> const char *otg_state_string(enum usb_otg_state state)
> {
> switch (state) {
> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> index a29ae1e..e7eb429 100644
> --- a/include/linux/usb/phy.h
> +++ b/include/linux/usb/phy.h
> @@ -106,6 +106,21 @@ struct usb_phy {
> enum usb_device_speed speed);
> };
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] efivars write(2) races
On Fri, 2013-01-25 at 11:50 +0800, Lingzhu Xiang wrote: > On 01/25/2013 08:25 AM, Al Viro wrote: > > 1) process A does write() on efivars file, reaches ->get_variable(), > > gets newdatasize set, drops efivars->lock and loses CPU before an attempt to > > grab ->i_mutex. process B comes and does the same thing, replacing the > > variable contents. Then it grabs ->i_mutex, updates size, drops ->i_mutex > > and buggers off. At which point A gets CPU back and proceeds to set size > > to whatever would be valid for its write. Only the value is bogus now... > > There are a few other things that makes size bogus now. > > 1. truncate() never touches nvram but pretends to be changing size. Good catch. Looks like we need to provide an implementation for this. > 2. Empty files come back with non-zero size after remount. They are imported >from sysfs when mounting. Eeek. The return value of get_variable() isn't checked in efivarfs_fill_super(). > 3. Arguably reading empty files could just return empty instead of returning >EIO/EFI_NOT_FOUND from firmware. Yeah, I think Jeremy has a patch to fix this. > 4. EFI_VARIABLE_APPEND_WRITE with EFI_OUT_OF_RESOURCES truncates size but you >can still read its content. I'm not sure what you mean by this. Could you please explain? Thanks for the feedback. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 Bug fix 0/5] Bug fix for physical memory hot-remove.
On Wed 23-01-13 06:29:31, Simon Jeons wrote: > On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote: > > Here are some bug fix patches for physical memory hot-remove. All these > > patches are based on the latest -mm tree. > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm > > > > And patch1 and patch3 are very important. > > patch1: free compound pages when freeing memmap, otherwise the kernel > > will panic the next time memory is hot-added. > > patch3: the old way of freeing pagetable pages was wrong. We should never > > split larger pages into small ones. > > > > > > Hi Tang, > > I remember your big physical memory hot-remove patchset has already > merged by Andrew, but where I can find it? Could you give me git tree > address? Andrew tree is also mirrored into a git tree. http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary It contains only Memory management patches on top of the last major release (since-.X.Y branch). -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND V5 5/6] perf, x86: Allow for architecture specific RDPMC indexes
On Thu, Jan 10, 2013 at 8:50 PM, Jacob Shin wrote:
> Similar to config_base and event_base, allow architecture specific
> RDPMC ECX values.
>
> Signed-off-by: Jacob Shin
Acked-by: Stephane Eranian
> ---
> arch/x86/kernel/cpu/perf_event.c |2 +-
> arch/x86/kernel/cpu/perf_event.h |6 ++
> arch/x86/kernel/cpu/perf_event_amd.c |6 ++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event.c
> b/arch/x86/kernel/cpu/perf_event.c
> index 4428fd1..b63982b 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -835,7 +835,7 @@ static inline void x86_assign_hw_event(struct perf_event
> *event,
> } else {
> hwc->config_base = x86_pmu_config_addr(hwc->idx);
> hwc->event_base = x86_pmu_event_addr(hwc->idx);
> - hwc->event_base_rdpmc = hwc->idx;
> + hwc->event_base_rdpmc = x86_pmu_rdpmc_index(hwc->idx);
> }
> }
>
> diff --git a/arch/x86/kernel/cpu/perf_event.h
> b/arch/x86/kernel/cpu/perf_event.h
> index 4440218..c910657 100644
> --- a/arch/x86/kernel/cpu/perf_event.h
> +++ b/arch/x86/kernel/cpu/perf_event.h
> @@ -326,6 +326,7 @@ struct x86_pmu {
> unsignedeventsel;
> unsignedperfctr;
> int (*addr_offset)(int index, int eventsel);
> + int (*rdpmc_index)(int index);
> u64 (*event_map)(int);
> int max_events;
> int num_counters;
> @@ -459,6 +460,11 @@ static inline unsigned int x86_pmu_event_addr(int index)
> (x86_pmu.addr_offset ? x86_pmu.addr_offset(index, 0) : index);
> }
>
> +static inline int x86_pmu_rdpmc_index(int index)
> +{
> + return x86_pmu.rdpmc_index ? x86_pmu.rdpmc_index(index) : index;
> +}
> +
> int x86_setup_perfctr(struct perf_event *event);
>
> int x86_pmu_hw_config(struct perf_event *event);
> diff --git a/arch/x86/kernel/cpu/perf_event_amd.c
> b/arch/x86/kernel/cpu/perf_event_amd.c
> index ef1df38..faf9072 100644
> --- a/arch/x86/kernel/cpu/perf_event_amd.c
> +++ b/arch/x86/kernel/cpu/perf_event_amd.c
> @@ -173,6 +173,11 @@ static inline int amd_pmu_addr_offset(int index, int
> eventsel)
> return offset;
> }
>
> +static inline int amd_pmu_rdpmc_index(int index)
> +{
> + return index;
> +}
> +
> static int amd_pmu_hw_config(struct perf_event *event)
> {
> int ret;
> @@ -620,6 +625,7 @@ static __initconst const struct x86_pmu amd_pmu = {
> .eventsel = MSR_K7_EVNTSEL0,
> .perfctr= MSR_K7_PERFCTR0,
> .addr_offset= amd_pmu_addr_offset,
> + .rdpmc_index= amd_pmu_rdpmc_index,
> .event_map = amd_pmu_event_map,
> .max_events = ARRAY_SIZE(amd_perfmon_event_map),
> .num_counters = AMD64_NUM_COUNTERS,
> --
> 1.7.9.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] aio: Fix a null pointer deref in batch_complete_aio
On Fri, Jan 25, 2013 at 5:43 AM, Kent Overstreet wrote:
> The batch completion code was trying to be a bit too clever, and skip
> checking ctx where it couldn't be NULL - but that broke if a kiocb had
> been cancelled. Move the check to kioctx_ring_unlock().
>
> Reported-by: Valdis Kletnieks
> Signed-off-by: Kent Overstreet
> ---
Acked-by: Hillf Danton
> fs/aio.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/aio.c b/fs/aio.c
> index 62573d3..0d2f39d 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -683,6 +683,9 @@ static inline void kioctx_ring_unlock(struct kioctx *ctx,
> unsigned tail)
> {
> struct aio_ring *ring;
>
> + if (!ctx)
> + return;
> +
> smp_wmb();
> /* make event visible before updating tail */
>
> @@ -760,8 +763,7 @@ void batch_complete_aio(struct batch_complete *batch)
> }
>
> if (unlikely(req->ki_ctx != ctx)) {
> - if (ctx)
> - kioctx_ring_unlock(ctx, tail);
> + kioctx_ring_unlock(ctx, tail);
>
> ctx = req->ki_ctx;
> tail = kioctx_ring_lock(ctx);
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] panda board locks up on boot
On Fri, 2013-01-25 at 08:43 +, Mats Liljegren wrote:
> Hi Steven,
>
> Do you have CONFIG_CPU_FREQ enabled? As I posted earlier in
> linux-kernel forum ("Failed booting PandaBoard ES with Linux 3.8 RC4"
> two days ago) my PandaBoard ES hangs while booting with this option
> enabled. It works fine without it. I have not bisected it down to a
> single commit though.
>
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
I guess that's not the issue I have.
Thanks,
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
On 01/25/2013 02:04 PM, Florian Vaussard wrote:
>>> @@ -153,6 +182,8 @@ static int led_pwm_probe(struct platform_device *pdev)
>>> led_dat->cdev.max_brightness = cur_led->max_brightness;
>>> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>>>
>>> +INIT_WORK(_dat->work, led_pwm_work);
>>
>> If we query the can_sleep before we can skip the INIT_WORK() when it is not
>> set.
>>
>
> I will do like this.
On the other hand you should also check at remove time that you are not going
to cancel a work on a non initialized one.
>
>>> +
>>> ret = led_classdev_register(>dev, _dat->cdev);
>>> if (ret < 0)
>>> goto err;
>>> @@ -180,8 +211,10 @@ static int led_pwm_remove(struct platform_device *pdev)
>>> struct led_pwm_priv *priv = platform_get_drvdata(pdev);
>>> int i;
>>>
>>> -for (i = 0; i < priv->num_leds; i++)
>>> +for (i = 0; i < priv->num_leds; i++) {
>>> led_classdev_unregister(>leds[i].cdev);
>>> +cancel_work_sync(>leds[i].work);
>>> +}
>>>
>>> return 0;
>>> }
>>>
>>
>>
>
> Thank you,
>
> Florian
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform
On Fri, Jan 25, 2013 at 01:57:51PM +0100, Linus Walleij wrote: > On Fri, Jan 25, 2013 at 1:55 PM, Linus Walleij > wrote: > > On Fri, Jan 25, 2013 at 1:46 PM, Jason Cooper wrote: > >> On Fri, Jan 25, 2013 at 09:17:57AM +0100, Linus Walleij wrote: > >>> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT > >>> wrote: > >>> > >>> > The Globalscale Mirabox platform can be connected to the JTAG/GPIO box > >>> > through the Multi-IO port. The GPIO box use the NXP PCA9505 I/O port > >>> > expansion IC to provide 40-bit parallel input/output GPIOs. This patch > >>> > enable the use of this expander on the Mirabox. > >>> > > >>> > Signed-off-by: Gregory CLEMENT > >>> > Acked-by: Linus Walleij > >>> > >>> So as requested I leave this patch for now, tell me if you want it > >>> applied through pinctrl. > >> > >> Which branch did you put the first two on? I'm not seeing them. > > > > Not pushed yet, take it easy. > > Or yeah, they are there: > http://git.kernel.org/?p=linux/kernel/git/linusw/linux-gpio.git;a=shortlog;h=refs/heads/devel Ahh, I had your pinctrl tree as a remote, but not gpio. Fixed, thanks. Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
Le 25/01/2013 13:53, Peter Ujfalusi a écrit :
On 01/25/2013 11:01 AM, Florian Vaussard wrote:
Call to led_pwm_set() can happen inside atomic context, like triggers.
If the PWM call can sleep, defer using a worker.
Signed-off-by: Florian Vaussard
---
drivers/leds/leds-pwm.c | 45 +++--
1 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index a1ea5f6..1ffb6ba 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -23,12 +23,15 @@
#include
#include
#include
+#include
struct led_pwm_data {
struct led_classdev cdev;
struct pwm_device *pwm;
+ struct work_struct work;
unsigned intactive_low;
unsigned intperiod;
+ int duty;
Would it be better if we also store the can_sleep in led_pwm_data struct and
initialize it when we probe the LEDs? It is not going to change runtime and we
will save one API call every time the LED has been changed.
Indeed, we will save a call each time. I will do it.
};
struct led_pwm_priv {
@@ -36,6 +39,20 @@ struct led_pwm_priv {
struct led_pwm_data leds[0];
};
+static void led_pwm_work(struct work_struct *work)
+{
+ struct led_pwm_data *led_dat =
+ container_of(work, struct led_pwm_data, work);
+ int new_duty = led_dat->duty;
+
+ pwm_config(led_dat->pwm, new_duty, led_dat->period);
+
+ if (new_duty == 0)
+ pwm_disable(led_dat->pwm);
+ else
+ pwm_enable(led_dat->pwm);
+}
I think we can remove the duplicated code by doing something like this:
static void __led_pwm_set(struct led_pwm_data *led_dat)
{
int new_duty = led_dat->duty;
pwm_config(led_dat->pwm, new_duty, led_dat->period);
if (new_duty == 0)
pwm_disable(led_dat->pwm);
else
pwm_enable(led_dat->pwm);
}
static void led_pwm_work(struct work_struct *work)
{
struct led_pwm_data *led_dat =
container_of(work, struct led_pwm_data, work);
__led_pwm_set(led_dat);
}
static void led_pwm_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
struct led_pwm_data *led_dat =
container_of(led_cdev, struct led_pwm_data, cdev);
unsigned int max = led_dat->cdev.max_brightness;
led_dat->duty = brightness * led_dat->period / max;
if (led_dat->can_sleep)
schedule_work(_dat->work);
else
__led_pwm_set(led_dat);
}
What do you think?
It is much better :)
+
static void led_pwm_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -43,13 +60,23 @@ static void led_pwm_set(struct led_classdev *led_cdev,
container_of(led_cdev, struct led_pwm_data, cdev);
unsigned int max = led_dat->cdev.max_brightness;
unsigned int period = led_dat->period;
+ int duty;
- if (brightness == 0) {
- pwm_config(led_dat->pwm, 0, period);
- pwm_disable(led_dat->pwm);
+ if (brightness == 0)
+ duty = 0;
+ else
+ duty = brightness * period / max;
+
+ if (pwm_can_sleep(led_dat->pwm)) {
+ led_dat->duty = duty;
+ schedule_work(_dat->work);
} else {
- pwm_config(led_dat->pwm, brightness * period / max, period);
- pwm_enable(led_dat->pwm);
+ pwm_config(led_dat->pwm, duty, period);
+
+ if (duty == 0)
+ pwm_disable(led_dat->pwm);
+ else
+ pwm_enable(led_dat->pwm);
}
}
@@ -100,6 +127,8 @@ static struct led_pwm_priv *led_pwm_create_of(struct
platform_device *pdev)
led_dat->cdev.brightness = LED_OFF;
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
+ INIT_WORK(_dat->work, led_pwm_work);
+
ret = led_classdev_register(>dev, _dat->cdev);
if (ret < 0) {
dev_err(>dev, "failed to register for %s\n",
@@ -153,6 +182,8 @@ static int led_pwm_probe(struct platform_device *pdev)
led_dat->cdev.max_brightness = cur_led->max_brightness;
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
+ INIT_WORK(_dat->work, led_pwm_work);
If we query the can_sleep before we can skip the INIT_WORK() when it is not set.
I will do like this.
+
ret = led_classdev_register(>dev, _dat->cdev);
if (ret < 0)
goto err;
@@ -180,8 +211,10 @@ static int led_pwm_remove(struct platform_device *pdev)
struct led_pwm_priv *priv = platform_get_drvdata(pdev);
int i;
- for (i = 0; i < priv->num_leds; i++)
+ for
Re: [PATCH 2/5] jump label: constify lookup functions
On Fri, 2013-01-25 at 11:16 +0100, Borislav Petkov wrote: > On Thu, Jan 24, 2013 at 11:15:10PM -0500, Sasha Levin wrote: > > Sorry about this. I didn't have the ability to build all arches over here :( > > Seen this already: https://www.kernel.org/pub/tools/crosstool/ And look in the kernel tree: tools/testing/ktest/examples/crosstests.conf -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform
On Fri, Jan 25, 2013 at 01:55:04PM +0100, Linus Walleij wrote: > On Fri, Jan 25, 2013 at 1:46 PM, Jason Cooper wrote: > > On Fri, Jan 25, 2013 at 09:17:57AM +0100, Linus Walleij wrote: > >> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT > >> wrote: > >> > >> > The Globalscale Mirabox platform can be connected to the JTAG/GPIO box > >> > through the Multi-IO port. The GPIO box use the NXP PCA9505 I/O port > >> > expansion IC to provide 40-bit parallel input/output GPIOs. This patch > >> > enable the use of this expander on the Mirabox. > >> > > >> > Signed-off-by: Gregory CLEMENT > >> > Acked-by: Linus Walleij > >> > >> So as requested I leave this patch for now, tell me if you want it > >> applied through pinctrl. > > > > Which branch did you put the first two on? I'm not seeing them. > > Not pushed yet, take it easy. Ahh, ok. Sorry, I wasn't trying to rush you. I didn't check the timestamps. Just saw it in my inbox this morning and decided to work on it before going to work. I'll check later, thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH Resend 1/3] sched: fix nr_busy_cpus with coupled cpuidle
2013/1/25 Vincent Guittot : > This sequence is not the right one > >> I'm going to look for the saved trace to check the sequence above > > I haven't been able to reproduce the bug that this patch was supposed to > solved. The patch 2 and 3 seem enough to fix the nr_busy_cpus field. I will > continue to try to reproduce it but it seems that it was a side effect of > the 2 others fixes of the series Ok. I just checked again as well and I can't find a scenario where this can happen. If you find it out or trigger the bug again, don't hesitate to resend this patch. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform
On Fri, Jan 25, 2013 at 1:55 PM, Linus Walleij wrote: > On Fri, Jan 25, 2013 at 1:46 PM, Jason Cooper wrote: >> On Fri, Jan 25, 2013 at 09:17:57AM +0100, Linus Walleij wrote: >>> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT >>> wrote: >>> >>> > The Globalscale Mirabox platform can be connected to the JTAG/GPIO box >>> > through the Multi-IO port. The GPIO box use the NXP PCA9505 I/O port >>> > expansion IC to provide 40-bit parallel input/output GPIOs. This patch >>> > enable the use of this expander on the Mirabox. >>> > >>> > Signed-off-by: Gregory CLEMENT >>> > Acked-by: Linus Walleij >>> >>> So as requested I leave this patch for now, tell me if you want it >>> applied through pinctrl. >> >> Which branch did you put the first two on? I'm not seeing them. > > Not pushed yet, take it easy. Or yeah, they are there: http://git.kernel.org/?p=linux/kernel/git/linusw/linux-gpio.git;a=shortlog;h=refs/heads/devel Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform
On Fri, Jan 25, 2013 at 1:46 PM, Jason Cooper wrote: > On Fri, Jan 25, 2013 at 09:17:57AM +0100, Linus Walleij wrote: >> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT >> wrote: >> >> > The Globalscale Mirabox platform can be connected to the JTAG/GPIO box >> > through the Multi-IO port. The GPIO box use the NXP PCA9505 I/O port >> > expansion IC to provide 40-bit parallel input/output GPIOs. This patch >> > enable the use of this expander on the Mirabox. >> > >> > Signed-off-by: Gregory CLEMENT >> > Acked-by: Linus Walleij >> >> So as requested I leave this patch for now, tell me if you want it >> applied through pinctrl. > > Which branch did you put the first two on? I'm not seeing them. Not pushed yet, take it easy. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpiolib-acpi: Add ACPI5 event model support to gpio.
On Fri, Jan 25, 2013 at 12:48 PM, Mathias Nyman wrote: > Add ability to handle ACPI events signalled by GPIO interrupts. > > ACPI5 platforms can use GPIO signaled ACPI events. These GPIO interrupts are > handled by ACPI event methods which need to be called from the GPIO > controller's interrupt handler. acpi_gpio_request_interrupt() finds out which > gpio pins have acpi event methods and assigns interrupt handlers that calls > the acpi event methods for those pins. > > Partially based on work by Rui Zhang > > Signed-off-by: Mathias Nyman (...) > +/** > + * acpi_gpio_request_interrupt() - Register isr for gpio controller ACPI > events > + * @chip: gpio chip representation of the gpio controller Hm chip, controller, controller, chip chip, controller controller... Are we using two different names for the same thing? > + * > + * ACPI5 platforms can use GPIO signaled ACPI events. These GPIO interrupts > are > + * handled by ACPI event methods which need to be called from the GPIO > + * controller's interrupt handler. acpi_gpio_request_interrupt finds out > which > + * gpio pins have acpi event methods and assigns interrupt handlers that > calls > + * the acpi event methods for those pins. > + */ > + > +void acpi_gpio_request_interrupt(struct gpio_chip *chip) So I was like "um, what acpi requests an interrupt for a GPIO (maybe a pin)... ... read read ... Aha the function should probably be named: acpi_gpiochip_request_interrupts() Because it just grabs all IRQs coming from that chip right? Second: why is there no mirror function *releasing* all the IRQs again? One-way interface? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
On 01/25/2013 11:01 AM, Florian Vaussard wrote:
> Call to led_pwm_set() can happen inside atomic context, like triggers.
> If the PWM call can sleep, defer using a worker.
>
> Signed-off-by: Florian Vaussard
> ---
> drivers/leds/leds-pwm.c | 45 +++--
> 1 files changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index a1ea5f6..1ffb6ba 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -23,12 +23,15 @@
> #include
> #include
> #include
> +#include
>
> struct led_pwm_data {
> struct led_classdev cdev;
> struct pwm_device *pwm;
> + struct work_struct work;
> unsigned intactive_low;
> unsigned intperiod;
> + int duty;
Would it be better if we also store the can_sleep in led_pwm_data struct and
initialize it when we probe the LEDs? It is not going to change runtime and we
will save one API call every time the LED has been changed.
> };
>
> struct led_pwm_priv {
> @@ -36,6 +39,20 @@ struct led_pwm_priv {
> struct led_pwm_data leds[0];
> };
>
> +static void led_pwm_work(struct work_struct *work)
> +{
> + struct led_pwm_data *led_dat =
> + container_of(work, struct led_pwm_data, work);
> + int new_duty = led_dat->duty;
> +
> + pwm_config(led_dat->pwm, new_duty, led_dat->period);
> +
> + if (new_duty == 0)
> + pwm_disable(led_dat->pwm);
> + else
> + pwm_enable(led_dat->pwm);
> +}
I think we can remove the duplicated code by doing something like this:
static void __led_pwm_set(struct led_pwm_data *led_dat)
{
int new_duty = led_dat->duty;
pwm_config(led_dat->pwm, new_duty, led_dat->period);
if (new_duty == 0)
pwm_disable(led_dat->pwm);
else
pwm_enable(led_dat->pwm);
}
static void led_pwm_work(struct work_struct *work)
{
struct led_pwm_data *led_dat =
container_of(work, struct led_pwm_data, work);
__led_pwm_set(led_dat);
}
static void led_pwm_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
struct led_pwm_data *led_dat =
container_of(led_cdev, struct led_pwm_data, cdev);
unsigned int max = led_dat->cdev.max_brightness;
led_dat->duty = brightness * led_dat->period / max;
if (led_dat->can_sleep)
schedule_work(_dat->work);
else
__led_pwm_set(led_dat);
}
What do you think?
> +
> static void led_pwm_set(struct led_classdev *led_cdev,
> enum led_brightness brightness)
> {
> @@ -43,13 +60,23 @@ static void led_pwm_set(struct led_classdev *led_cdev,
> container_of(led_cdev, struct led_pwm_data, cdev);
> unsigned int max = led_dat->cdev.max_brightness;
> unsigned int period = led_dat->period;
> + int duty;
>
> - if (brightness == 0) {
> - pwm_config(led_dat->pwm, 0, period);
> - pwm_disable(led_dat->pwm);
> + if (brightness == 0)
> + duty = 0;
> + else
> + duty = brightness * period / max;
> +
> + if (pwm_can_sleep(led_dat->pwm)) {
> + led_dat->duty = duty;
> + schedule_work(_dat->work);
> } else {
> - pwm_config(led_dat->pwm, brightness * period / max, period);
> - pwm_enable(led_dat->pwm);
> + pwm_config(led_dat->pwm, duty, period);
> +
> + if (duty == 0)
> + pwm_disable(led_dat->pwm);
> + else
> + pwm_enable(led_dat->pwm);
> }
> }
>
> @@ -100,6 +127,8 @@ static struct led_pwm_priv *led_pwm_create_of(struct
> platform_device *pdev)
> led_dat->cdev.brightness = LED_OFF;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + INIT_WORK(_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(>dev, _dat->cdev);
> if (ret < 0) {
> dev_err(>dev, "failed to register for %s\n",
> @@ -153,6 +182,8 @@ static int led_pwm_probe(struct platform_device *pdev)
> led_dat->cdev.max_brightness = cur_led->max_brightness;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + INIT_WORK(_dat->work, led_pwm_work);
If we query the can_sleep before we can skip the INIT_WORK() when it is not set.
> +
> ret = led_classdev_register(>dev, _dat->cdev);
> if (ret < 0)
> goto err;
> @@ -180,8 +211,10 @@ static int led_pwm_remove(struct platform_device *pdev)
> struct led_pwm_priv *priv = platform_get_drvdata(pdev);
> int i;
>
> - for (i = 0; i < priv->num_leds; i++)
> + for (i = 0; i < priv->num_leds; i++) {
>
