* Re: [PATCH] [TRIVIAL] ARM: imx: Fix typo 'MACH_MX31_3DS_MXC_NAND_USE_BBT'
From: Jiri Kosina @ 2011-10-31 10:12 UTC (permalink / raw)
To: Paul Bolle
Cc: linux-kernel, Russell King, linux-arm-kernel, Fabio Estevam,
Uwe Kleine-König
In-Reply-To: <1318421062.2336.4.camel@x61.thuisdomein>
On Wed, 12 Oct 2011, Paul Bolle wrote:
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> This is trivial because this is what apparently was intended. On the
> other hand this should open code paths that were hidden until now. So
> perhaps this needs the maintainer's approval. (I cannot meaningfully
> test this.)
I'd like to have this tested by some relevant people before taking it
myself (added some CCs).
>
> arch/arm/mach-imx/mach-mx31_3ds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
> index c20be75..5750ca5 100644
> --- a/arch/arm/mach-imx/mach-mx31_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx31_3ds.c
> @@ -542,7 +542,7 @@ static const struct mxc_nand_platform_data
> mx31_3ds_nand_board_info __initconst = {
> .width = 1,
> .hw_ecc = 1,
> -#ifdef MACH_MX31_3DS_MXC_NAND_USE_BBT
> +#ifdef CONFIG_MACH_MX31_3DS_MXC_NAND_USE_BBT
> .flash_bbt = 1,
> #endif
> };
> --
> 1.7.4.4
>
>
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] [TRIVIAL] ARM: imx: Fix typo 'MACH_MX31_3DS_MXC_NAND_USE_BBT'
From: Jiri Kosina @ 2011-10-31 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318421062.2336.4.camel@x61.thuisdomein>
On Wed, 12 Oct 2011, Paul Bolle wrote:
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> This is trivial because this is what apparently was intended. On the
> other hand this should open code paths that were hidden until now. So
> perhaps this needs the maintainer's approval. (I cannot meaningfully
> test this.)
I'd like to have this tested by some relevant people before taking it
myself (added some CCs).
>
> arch/arm/mach-imx/mach-mx31_3ds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
> index c20be75..5750ca5 100644
> --- a/arch/arm/mach-imx/mach-mx31_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx31_3ds.c
> @@ -542,7 +542,7 @@ static const struct mxc_nand_platform_data
> mx31_3ds_nand_board_info __initconst = {
> .width = 1,
> .hw_ecc = 1,
> -#ifdef MACH_MX31_3DS_MXC_NAND_USE_BBT
> +#ifdef CONFIG_MACH_MX31_3DS_MXC_NAND_USE_BBT
> .flash_bbt = 1,
> #endif
> };
> --
> 1.7.4.4
>
>
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [Buildroot] [buildroot] Building opencv for OMAP4430 / Armv7 / Cmake problem
From: Bruno Niklaus @ 2011-10-31 10:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CANVadiHy0cddWJrWqF6RPS2QLp-yjY1yPYUhXm2si27m0C7M8g@mail.gmail.com>
what works too is to change
*-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE*
to
*-DZLIB_LARGEFILE_SOURCE -DZLIB_LARGEFILE64_SOURCE*
in the toolchainfile.cmake
i really don't know whats the difference, but it works. i tried this
according
to this mail
http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-April/001864.html
---------- Forwarded message ----------
From: Bruno Niklaus <niklaus.bruno@gmail.com>
Date: 2011/10/31
Subject: Building opencv for OMAP4430 / Armv7 / Cmake problem
To: buildroot at busybox.net
Hi @all
i tried to build opencv for armv7 / omap4430 processor, i'm using
codesourcery toolchain with neon optimations enabled.
when cmake tries to build opencv i allways get strange error with
*"z_offset64_t"*
The generated "toolchainfile.cmake" file in the "buildroot/outpout"
directory sets additional CMAKE_C_FLAGS and CMAKE_CXX_FLAGS at the end:
*"-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"*
I dont think these are the right flags, if i delete them and rebuild opencv
i runs trough without any errors.
but i dont know where the toolchainfile.cmake is generated? Where should i
apply a patch?
And is it okay to just delete the flags or should there be other flags?
best regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111031/4ad689d1/attachment.html>
^ permalink raw reply
* Re: [PATCH] s3c2410: remove __ioaddrc()
From: Russell King - ARM Linux @ 2011-10-31 10:11 UTC (permalink / raw)
To: Cesar Eduardo Barros; +Cc: Ben Dooks, linux-arm-kernel, linux-kernel
In-Reply-To: <1319916749-14899-1-git-send-email-cesarb@cesarb.net>
On Sat, Oct 29, 2011 at 05:32:29PM -0200, Cesar Eduardo Barros wrote:
> While looking at s3c2410's mach/io.h, I noticed the #define for
> __ioaddr() looked wrong. While the #defines above it called the "c"
> suffixed variant when __builtin_constant_p() was true, the one for
> __ioaddr() called the "c" suffixed variant (__ioaddrc()) when
> __builtin_constant_p() was *false*.
>
> Looking further, I noticed that __ioaddr() and __ioaddrc() were
> identical, the only difference being that __ioaddr() is an inline
> function and __ioaddrc() is a macro.
>
> __ioaddrc() is not used anywhere else. There were similar constructs,
> also reversed from what I'd expect, in both mach-clps7500 (removed from
> the kernel in 2.6.29) and mach-rpc. The copy in mach-rpc was removed in
> commit 6de2c31d3dad7384b3efa03674bd6ed479d58cb2 (rpc: remove obsolete IO
> accessors).
>
> Since __ioaddrc() is both redundant and useless, has no other uses, and
> has already been removed in mach-rpc, remove it also in mach-s3c2410.
Good. Now, what about that horrible fudge in the inb/outb etc accessors.
Can that be killed off as well?
^ permalink raw reply
* [PATCH] s3c2410: remove __ioaddrc()
From: Russell King - ARM Linux @ 2011-10-31 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319916749-14899-1-git-send-email-cesarb@cesarb.net>
On Sat, Oct 29, 2011 at 05:32:29PM -0200, Cesar Eduardo Barros wrote:
> While looking at s3c2410's mach/io.h, I noticed the #define for
> __ioaddr() looked wrong. While the #defines above it called the "c"
> suffixed variant when __builtin_constant_p() was true, the one for
> __ioaddr() called the "c" suffixed variant (__ioaddrc()) when
> __builtin_constant_p() was *false*.
>
> Looking further, I noticed that __ioaddr() and __ioaddrc() were
> identical, the only difference being that __ioaddr() is an inline
> function and __ioaddrc() is a macro.
>
> __ioaddrc() is not used anywhere else. There were similar constructs,
> also reversed from what I'd expect, in both mach-clps7500 (removed from
> the kernel in 2.6.29) and mach-rpc. The copy in mach-rpc was removed in
> commit 6de2c31d3dad7384b3efa03674bd6ed479d58cb2 (rpc: remove obsolete IO
> accessors).
>
> Since __ioaddrc() is both redundant and useless, has no other uses, and
> has already been removed in mach-rpc, remove it also in mach-s3c2410.
Good. Now, what about that horrible fudge in the inb/outb etc accessors.
Can that be killed off as well?
^ permalink raw reply
* Re: [PATCH RFC v2 00/13] New event API
From: Ian Campbell @ 2011-10-31 10:11 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
On Fri, 2011-10-28 at 19:36 +0100, Ian Jackson wrote:
> This is a revised RFC version of my event handling API proposal.
>
> It consists of 10 rather uninteresting preparatory, stylistic
> and bugfix patches, plus 3 with some meat in:
> 02/13 libxenstore: Provide xs_check_watch
> 12/13 libxl: New API for providing OS events to libxl
> 13/13 libxl: New event generation API
>
> This series contains an implementation of almost everything, and
> builds apart from the lack of libxl_event_free, but it has not been
> executed at all.
>
> So at this stage a very detailed code review, particularly of 12 and
> 13 is probably not appropriate. However, this is hopefully a
> near-final version of the external and internal interfaces so it would
> be worth looking at those.
I reviewed all but #12 and #13 so far and I think they can mostly go in
now, at least in principal. I acked the majority with that in mind.
I suppose the ones which introduce new facilities should/could wait for
the actual users (which I presume are in #12 and #13) which I guess was
your intent but I think #1, #3, #5, #8, #10 and #11 would be obviously
fine right now.
#3 is a bit borderline wrt having a user but I think you wanted
libxl_qmp.c to use it so bashing it in now makes sense?
Ian.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 03/13] qemu-timer: move common code to qemu_rearm_alarm_timer
From: Paolo Bonzini @ 2011-10-31 10:05 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <CAETRQW=RzJqWSHrqCyH9p50yyZx83NQ3uCe+1Vex_T+G9tsGOA@mail.gmail.com>
On 10/31/2011 08:23 AM, TeLeMan wrote:
>> > static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
>> > {
>> > - if (!alarm_has_dynticks(t))
>> > + int64_t nearest_delta_ns;
>> > + assert(alarm_has_dynticks(t));
> "mmtimer" and "win32" alarms have no rearm. Should we remove these two alarms?
Yes. I think with iothread they are broken, or almost broken.
Paolo
^ permalink raw reply
* Re: [PATCH][mm/memory.c]: transparent hugepage check condition missed
From: Guan Jun He @ 2011-10-31 9:26 UTC (permalink / raw)
To: torvalds, Guan Jun He, linux-kernel
In-Reply-To: <1320051775-13992-1-git-send-email-gjhe@suse.com>
Excuse me! I got the one email sent 6 times!
best,
Guanjun
>>> On 10/31/2011 at 05:02 PM, in message
<1320051775-13992-1-git-send-email-gjhe@suse.com>, Guanjun He <gjhe@suse.com>
wrote:
> For the transparent hugepage module still does not support
> tmpfs and cache,the check condition should always be checked
> to make sure that it only affect the anonymous maps, the
> original check condition missed this, this patch is to fix this.
> Otherwise,the hugepage may affect the file-backed maps,
> then the cache for the small-size pages will be unuseful,
> and till now there is still no implementation for hugepage's cache.
>
> Signed-off-by: Guanjun He <gjhe@suse.com>
> ---
> mm/memory.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index a56e3ba..79b85fe 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3475,7 +3475,8 @@ int handle_mm_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> if (pmd_trans_huge(orig_pmd)) {
> if (flags & FAULT_FLAG_WRITE &&
> !pmd_write(orig_pmd) &&
> - !pmd_trans_splitting(orig_pmd))
> + !pmd_trans_splitting(orig_pmd) &&
> + !vma->vm_ops)
> return do_huge_pmd_wp_page(mm, vma, address,
> pmd, orig_pmd);
> return 0;
^ permalink raw reply
* [U-Boot] [PATCH] ARM: define CONFIG_MACH_TYPE for all keymile boards
From: Valentin Longchamp @ 2011-10-31 10:07 UTC (permalink / raw)
To: u-boot
As this is a mandatory CONFIG for ARM boards now.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
---
include/configs/km/km_arm.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index eaf6017..f30088d 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -48,6 +48,8 @@
#define CONFIG_KW88F6281 /* SOC Name */
#define CONFIG_MACH_KM_KIRKWOOD /* Machine type */
+#define CONFIG_MACH_TYPE MACH_TYPE_KM_KIRKWOOD
+
/* include common defines/options for all Keymile boards */
#include "keymile-common.h"
--
1.7.1
^ permalink raw reply related
* Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
From: Heiko Carstens @ 2011-10-31 10:05 UTC (permalink / raw)
To: James Bottomley
Cc: Jun'ichi Nomura, Steffen Maier, linux-scsi@vger.kernel.org,
Jens Axboe, Hannes Reinecke, Linux Kernel, Alan Stern,
Thadeu Lima de Souza Cascardo, Taraka R. Bodireddy,
Seshagiri N. Ippili, Manvanthara B. Puttashankar, Jeff Moyer,
Shaohua Li, Mike Snitzer, gmuelas
In-Reply-To: <1318955380.5169.15.camel@dabdike.int.hansenpartnership.com>
On Tue, Oct 18, 2011 at 11:29:40AM -0500, James Bottomley wrote:
> On Tue, 2011-10-18 at 17:45 +0200, Heiko Carstens wrote:
> > On Tue, Oct 18, 2011 at 10:31:20PM +0900, Jun'ichi Nomura wrote:
> > > On 10/17/11 23:06, James Bottomley wrote:
> > > > On Mon, 2011-10-17 at 17:46 +0900, Jun'ichi Nomura wrote:
> > > >> On 10/15/11 01:03, James Bottomley wrote:
> > > >>> On Thu, 2011-10-13 at 15:09 +0200, Steffen Maier wrote:
> > > >>>> Initially, we encountered use-after-free bugs in
> > > >>>> scsi_print_command / scsi_dispatch_cmd
> > > >>>> http://marc.info/?l=linux-scsi&m=130824013229933&w=2
> > > >>
> > > >> It is interesting that both this and the older report
> > > >> got oopsed in scsi_log_send(), while there are other
> > > >> dereferences of 'cmd' around scsi_dispatch_cmd().
> > > >> Are there any reason they are special? Just by accident?
> > > >
> > > > Right, that's why it looks like the command area got freed rather than
> > > > the command pointer was bogus (6b is a poison free pattern). Perhaps if
> > > > the reporter could pin down the failing source line, we'd know better
> > > > what was going on?
> > >
> > > Yeah, that might be useful.
> >
> > The struct scsi_cmnd that was passed to scsi_log_send() was already freed
> > (contents completely 6b6b6b...).
> > Since SLUB debugging was turned on we can see that it was freed from
> > __scsi_put_command(). Not too much of a surprise.
>
> But it does tell us the put must be racing with dispatch, since
> dereferencing the command to find the device worked higher up in
> scsi_dispatch_cmd().
>
> There is one way to invalidate the theory that we cloned something with
> an attached command, and that's to put
>
> BUG_ON(rq->special)
>
> in blk_insert_cloned_request(). I think we're careful about clearing
> it, so it should work (perhaps a warn on just in case).
It _looks_ like we do not hit the BUG_ON() that. This time we get this instead:
[ 4024.937870] Unable to handle kernel pointer dereference at virtual kernel address 000003e004d41000
[ 4024.937886] Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 4024.937899] Modules linked in: dm_round_robin sunrpc ipv6 qeth_l2 binfmt_misc dm_multipath scsi_dh dm_mod qeth ccwgroup [las
t unloaded: scsi_wait_scan]
[ 4024.937925] CPU: 1 Not tainted 3.0.7-50.x.20111021-s390xdefault #1
[ 4024.937930] Process ksoftirqd/1 (pid: 1942, task: 0000000079c6c750, ksp: 0000000073adfc50)
[ 4024.937936] Krnl PSW : 0704000180000000 000003e00126263a (dm_softirq_done+0x72/0x140 [dm_mod])
[ 4024.937959] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3
[ 4024.937966] Krnl GPRS: 000000007b9156b0 000003e004d41100 000000000e14b600 000000000000006d
[ 4024.937971] 00000000715332b0 000000000c140ce8 000000000090d2ef 0000000000000005
[ 4024.937977] 0000000000000001 0000000000000101 000000000c140d00 0000000000000000
[ 4024.937983] 000003e001260000 000003e00126f098 0000000073adfd08 0000000073adfcb8
[ 4024.938001] Krnl Code: 000003e00126262a: f0a0000407f1 srp 4(11,%r0),2033,0
[ 4024.938009] 000003e001262630: e31050080004 lg %r1,8(%r5)
[ 4024.938017] 000003e001262636: 58b05180 l %r11,384(%r5)
[ 4024.938024] >000003e00126263a: e31010080004 lg %r1,8(%r1)
[ 4024.938031] 000003e001262640: e31010500004 lg %r1,80(%r1)
[ 4024.938038] 000003e001262646: b9020011 ltgr %r1,%r1
[ 4024.938045] 000003e00126264a: a784ffdf brc 8,3e001262608
[ 4024.938053] 000003e00126264e: e32050080004 lg %r2,8(%r5)
[ 4024.938060] Call Trace:
[ 4024.938063] ([<070000000040716c>] 0x70000000040716c)
[ 4024.938069] [<000000000040d29c>] blk_done_softirq+0xd4/0xf0
[ 4024.938080] [<00000000001587c2>] __do_softirq+0xda/0x398
[ 4024.938088] [<0000000000158ba0>] run_ksoftirqd+0x120/0x23c
[ 4024.938095] [<000000000017c2aa>] kthread+0xa6/0xb0
[ 4024.938102] [<000000000061970e>] kernel_thread_starter+0x6/0xc
[ 4024.938112] [<0000000000619708>] kernel_thread_starter+0x0/0xc
[ 4024.938118] INFO: lockdep is turned off.
[ 4024.938121] Last Breaking-Event-Address:
[ 4024.938124] [<000003e001262600>] dm_softirq_done+0x38/0x140 [dm_mod]
[ 4024.938135]
[ 4024.938139] Kernel panic - not syncing: Fatal exception in interrupt
[ 4024.938144] CPU: 1 Tainted: G D 3.0.7-50.x.20111021-s390xdefault #1
[ 4024.938150] Process ksoftirqd/1 (pid: 1942, task: 0000000079c6c750, ksp: 0000000073adfc50)
[ 4024.938155] 0000000073adf958 0000000073adf8d8 0000000000000002 0000000000000000
[ 4024.938164] 0000000073adf978 0000000073adf8f0 0000000073adf8f0 000000000061386a
[ 4024.938174] 0000000000000000 0000000000000000 0000000000000005 0000000000100ec6
[ 4024.938184] 000000000000000d 000000000000000c 0000000073adf940 0000000000000000
[ 4024.938194] 0000000000000000 0000000000100a18 0000000073adf8d8 0000000073adf918
[ 4024.938205] Call Trace:
[ 4024.938208] ([<0000000000100926>] show_trace+0xee/0x144)
[ 4024.938216] [<0000000000613694>] panic+0xb0/0x234
[ 4024.938224] [<0000000000100ec6>] die+0x15a/0x168
[ 4024.938230] [<000000000011fb9e>] do_no_context+0xba/0xf8
[ 4024.938306] [<000000000061c074>] do_dat_exception+0x378/0x3e4
[ 4024.938314] [<0000000000619e02>] pgm_exit+0x0/0x4
[ 4024.938319] [<000003e00126263a>] dm_softirq_done+0x72/0x140 [dm_mod]
[ 4024.938329] ([<070000000040716c>] 0x70000000040716c)
[ 4024.938334] [<000000000040d29c>] blk_done_softirq+0xd4/0xf0
[ 4024.938341] [<00000000001587c2>] __do_softirq+0xda/0x398
[ 4024.938347] [<0000000000158ba0>] run_ksoftirqd+0x120/0x23c
[ 4024.938354] [<000000000017c2aa>] kthread+0xa6/0xb0
[ 4024.938360] [<000000000061970e>] kernel_thread_starter+0x6/0xc
[ 4024.938366] [<0000000000619708>] kernel_thread_starter+0x0/0xc
[ 4024.938373] INFO: lockdep is turned off.
So we thought we might as well upgrade to 3.1 but immediately got a
kernel BUG at block/blk-flush.c:323!
which was handled here https://lkml.org/lkml/2011/10/4/105 and
here https://lkml.org/lkml/2011/10/12/408 .
But no patches for that one went upstream AFAICS.
^ permalink raw reply
* Re: [PATCH RFC v2 11/13] libxl: make libxl__free_all idempotent
From: Ian Campbell @ 2011-10-31 10:05 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <1319827031-15395-12-git-send-email-ian.jackson@eu.citrix.com>
On Fri, 2011-10-28 at 19:37 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> tools/libxl/libxl_internal.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index df2b7f8..62e7fba 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
> free(ptr);
> }
> free(gc->alloc_ptrs);
> + gc->alloc_ptrs = 0;
> + gc->alloc_maxsize = 0;
> }
>
> void *libxl__zalloc(libxl__gc *gc, int bytes)
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/2] Better support for distros using /lib64 directories
From: Paolo Bonzini @ 2011-10-31 10:04 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1319993519-865-1-git-send-email-smizrahi@redhat.com>
On 10/30/2011 05:51 PM, Saggi Mizrahi wrote:
> Some distributions use lib64 directories for 64 bit libraries. Currently
> configure would always generate libdir as $PREFIX/lib. By checking if
> the current distro has a /lib64 directory we can assume it is using this
> convention.
This doesn't work if people compile a 32-bit version of QEMU. The right
directory could be obtained with "gcc --print-multi-os-directory
$CFLAGS", but I'm not sure whether it is a good thing to do. We should
try to avoid gratuitous differences from Autoconf.
The right thing to do would be to tweak the command-line supported by
configure to the point that packagers can just use the same command-line
that Autoconf uses (in RPM parlance that would be "%configure").
Paolo
^ permalink raw reply
* Re: [PATCH RFC v2 10/13] libxl: make libxl__[v]log const-correct
From: Ian Campbell @ 2011-10-31 10:04 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <1319827031-15395-11-git-send-email-ian.jackson@eu.citrix.com>
On Fri, 2011-10-28 at 19:37 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> tools/libxl/libxl_internal.c | 4 ++--
> tools/libxl/libxl_internal.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index dd31f25..df2b7f8 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
>
> void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
> const char *file, int line, const char *func,
> - char *fmt, va_list ap)
> + const char *fmt, va_list ap)
> {
> char *enomem = "[out of memory formatting log message]";
> char *base = NULL;
> @@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>
> void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
> const char *file, int line, const char *func,
> - char *fmt, ...)
> + const char *fmt, ...)
> {
> va_list ap;
> va_start(ap, fmt);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 79a9de4..fe64d34 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -80,13 +80,13 @@
> _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
> const char *file /* may be 0 */, int line /* ignored if !file */,
> const char *func /* may be 0 */,
> - char *fmt, va_list al)
> + const char *fmt, va_list al)
> __attribute__((format(printf,7,0)));
>
> _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
> const char *file /* may be 0 */, int line /* ignored if !file */,
> const char *func /* may be 0 */,
> - char *fmt, ...)
> + const char *fmt, ...)
> __attribute__((format(printf,7,8)));
>
> /* these functions preserve errno (saving and restoring) */
^ permalink raw reply
* [Bug 42280] NVc0 generation card (0x0c1000a1) not working
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-31 10:04 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-42280-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42280
Bruno Antunes <sardaukar.siet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #8 from Bruno Antunes <sardaukar.siet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-10-31 03:04:02 PDT ---
Thanks for the help, Marcin! I was just adding "noaccel=0" without "nouveau."!
This whole process is really not straight-forward. The reporting should be
simpler and the docs are hard to grasp.
Enjoying default Gnome Shell now, thanks to you man! :D
Thanks a bunch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx
From: Ian Campbell @ 2011-10-31 10:03 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
On Fri, 2011-10-28 at 19:37 +0100, Ian Jackson wrote:
> This lock will be used to protect data structures which will be hung
> off the libxl_ctx in subsequent patches.
>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
> tools/libxl/libxl.c | 3 +++
> tools/libxl/libxl_internal.h | 16 ++++++++++++++++
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 5d448af..a3c9807 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -40,6 +40,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, xentoollog_logger * lg)
> {
> libxl_ctx *ctx;
> struct stat stat_buf;
> + const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>
> if (version != LIBXL_VERSION)
> return ERROR_VERSION;
> @@ -53,6 +54,8 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, xentoollog_logger * lg)
> memset(ctx, 0, sizeof(libxl_ctx));
> ctx->lg = lg;
>
> + memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
Is this subtly different to
ctx->lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
in some way I'm missing?
> +
> if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
> LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
> "failed to stat %s", XENSTORE_PID_FILE);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6d9da2c..79a9de4 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -23,6 +23,7 @@
> #include <stdarg.h>
> #include <stdlib.h>
> #include <string.h>
> +#include <pthread.h>
>
> #include <xs.h>
> #include <xenctrl.h>
> @@ -95,6 +96,9 @@ struct libxl__ctx {
> xc_interface *xch;
> struct xs_handle *xsh;
>
> + pthread_mutex_t lock; /* protects data structures hanging off the ctx */
> + /* always use MUTEX_LOCK and MUTEX_UNLOCK to manipulate this */
MUTEX is something of an implementation detail (although I admit we are
unlikely to use anything else), perhaps CTX_(UN)LOCK?
Perhaps give the variable a less obvious name to help discourage direct
use?
> +
> /* for callers who reap children willy-nilly; caller must only
> * set this after libxl_init and before any other call - or
> * may leave them untouched */
> @@ -577,6 +581,18 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
> #define CTX libxl__gc_owner(gc)
>
>
> +#define MUTEX_LOCK do { \
> + int mutex_r = pthread_mutex_lock(&CTX->lock); \
> + assert(!mutex_r); \
This assert is to catch EINVAL ("the mutex has not been properly
initialized") rather than EDEADLK ("the mutex is already locked by the
calling thread") since we asked for a non-error-checking recursive lock?
Since it is OK to take this lock recursively then it might be as well to
say so explicitly?
This is the first lock in libxl so I guess there isn't much of a locking
hierarchy yet. Are there any particular considerations which a caller
must make wrt its own locking?
> + } while(0)
> +
> +#define MUTEX_UNLOCK do { \
> + int mutex_r = pthread_mutex_unlock(&CTX->lock); \
> + assert(!mutex_r); \
> + } while(0)
> +
> +
> +
> /*
> * Inserts "elm_new" into the sorted list "head".
> *
^ permalink raw reply
* Re: [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic
From: Paul Eggleton @ 2011-10-31 9:55 UTC (permalink / raw)
To: Paul Menzel; +Cc: openembedded-devel
In-Reply-To: <1319891607.3756.18.camel@mattotaupa>
On Saturday 29 October 2011 13:33:27 Paul Menzel wrote:
> > +LIC_FILES_CHKSUM =
> > "files://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
> > +PR = "r0"
>
> According to Koen these are going away.
Well, Koen might reject PR = "r0" in meta-oe, that's fine; however
LIC_FILES_CHKSUM is mandatory or the recipe will not build, and I don't think
that will be changing any time soon. I have considered if it would be
desirable/possible to eliminate it for recipes that don't install any files
(e.g. tasks), so far I haven't done any work on that. For normal recipes it is
required however.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] [WIP]Added target to build libvdisk
From: Paolo Bonzini @ 2011-10-31 10:01 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4EAD91B1.40109@redhat.com>
On 10/30/2011 07:04 PM, Saggi Mizrahi wrote:
>>
>> I wonder also what thread API should be used, qemu_thread versions
>> used internally or standard ones. It would be logical to use
>> qemu_thread versions but then the external user should use those too.
> I would prefer not to use qemu's threading as it'll expose internal
> APIs. I suggest glib's threading,
Is it visible in any way to the client? Also, perhaps thread-safety
should be left to the client so that they can use whatever API they like?
Paolo
^ permalink raw reply
* RE: [PATCH] scheduler rate controller
From: Dario Faggioli @ 2011-10-31 9:59 UTC (permalink / raw)
To: George Dunlap
Cc: Tian, Kevin, xen-devel@lists.xensource.com, Keir (Xen.org),
George Dunlap, Dong, Eddie, Lv, Hui, Duan, Jiangang
In-Reply-To: <1319818714.21033.414.camel@elijah>
[-- Attachment #1.1: Type: text/plain, Size: 3147 bytes --]
On Fri, 2011-10-28 at 17:18 +0100, George Dunlap wrote:
> On Fri, 2011-10-28 at 11:09 +0100, Dario Faggioli wrote:
> > Not sure yet, I can imagine it's tricky and I need to dig a bit more in
> > the code, but I'll let know if I found a way of doing that...
>
> There are lots of reasons why the SCHEDULE_SOFTIRQ gets raised. But I
> think we want to focus on the scheduler itself raising it as a result of
> the .wake() callback. Whether the .wake() happens as a result of a HW
> interrupt or something else, I don't think really matters.
>
I fully agree, since these are the events that are likely to cause a
context switch, and it's the context switch that --when happening too
frequently-- trashes the performances, isn't it?
> Dario and Hui, neither of you have commented on my idea, which is
> simply don't preempt a VM if it has run for less than some amount of
> time (say, 500us or 1ms). If a higher-priority VM is woken up, see how
> long the current VM has run. If it's less than 1ms, set a 1ms timer and
> call schedule() then.
>
Right, I was about to, but the got busy with other stuff. To me, it
sounds a more than valid method for achieving similar results. Maybe I
like it more than pure rate-limiting because it makes it easier to
understand what's going on, especially from the final user point of
view, and thus also easier to configure and to be dealt with.
However, the effect is still pretty much the same, and this is also
able to cause "scheduling artifact", and affect guarantees and/or
expected behaviour, e.g., in EDF, if the earliest deadline task wakes up
right after a context switch it would need to run, independently on for
how long current is running, and not doing so could jeopardize
schedulability.
Again, I'm not saying something like that shouldn't be done at all, just
that --if it is something special kicking in from time to time-- it
should make itsself evident.
> As much as possible, we want the system to Just Work. Under normal
> circumstances it wouldn't be too unusual for a VM to have a several-ms
> delay between receiving a physical interrupt and being scheduled; I
> think that if the 1ms delay works, having it on all the time would
> probably be the best solution. That's another reason I'm in favor of
> trying it -- it's simple and easy to understand, and doesn't require
> detecting when to "turn it on".
>
Ok, that's the other way around. Having it all the time is pretty much
self evident so, if we're fine with the latency this introduces, and it
improves fairness and performances , this could be the way. From my
experience in real-time scheduling, ms alike scheduling latency is
something very very huge... But this obviously depend on the workload.
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Xenomai-help] xenomai on em2440
From: Gilles Chanteperdrix @ 2011-10-31 9:58 UTC (permalink / raw)
To: Eric Noulard; +Cc: xenomai
In-Reply-To: <CAPASGLrv71uw9NYEjxwhYfrz2kHZsSUFANVAegGGU4RBPW3_Ow@domain.hid>
On 10/30/2011 10:21 AM, Eric Noulard wrote:
.>> Can xenomai have multiple skins at the same time?
>
> Yes Xenomai may have mulitple skins
> (see slide 5 of http://www.xenomai.org/images/c/c6/Xenomai-OSMB-2007-01.pdf)
> but I don't know if a single application may use different skins at
> the same time.
> I never tried myself so I let other answer that one.
>
> Why would you want to have/use multiple skin?
>
An application may use multiple skins at the same time.
--
Gilles.
^ permalink raw reply
* [U-Boot] My Dearest one
From: Sofia Yak @ 2011-10-31 9:58 UTC (permalink / raw)
To: u-boot
My Dearest one,
Hi, My name is Sofia Justin Yak, 23years old originated from Sudan. I decide to contact you after my prayers, I really want to have a good relationship with you. My father Dr. Justin Yak was the former Minister for SPLA Affairs and Special Adviser to President Salva Kiir of South Sudan for Decentralization. My father Dr.Justin Yak and my mother including other top Military officers and top govaernment officials had been on board when the plane crashed on Friday May 02, 2008.
You can read more about the crash through the below site:
http://news.bbc.co.uk/2/hi/africa/7380412.stm
After the burial of my father, my uncle conspired and sold my father's properties to a Chinease Expatriate and live nothing for me. On a faithful morning, I opened my father's briefcase and found out the documents which he have deposited huge amount of money in one bank in Burkina Faso with my name as the next of kin. I traveled to Burkina Faso to withdraw the money so that I can start a better life and take care of myself. On my arrival, the Branch manager of the Bank whom I met in person told me that my father's instruction to the bank was the money be release to me only when I am married or present a trustee who will help me and invest the money overseas.
I have chosen to contact you after my prayers and I believe that you will not betray my trust. But rather take me as your own sister. Though you may wonder why I am so soon revealing myself to you without knowing you, well, I will say that my mind convinced me that you are the true person to help me. More so, I will like to disclose much to you if you can help me to relocate to your country because my uncle have threaten to assassinate me. The amount is $5.6 Million and I have confirmed from the bank in Burkina Faso. You will also help me to place the money in a more profitable business venture in your Country.
However, you will help by recommending a nice University in your country so that I can complete my studies. It is my intention to compensate you with 30% of the total money for your services and the balance shall be my capital in your establishment. As soon as I receive your interest in helping me, I will put things into action immediately. In the light of the above, I shall appreciate an urgent message indicating your ability and willingness to handle this transaction sincerely. Please do keep this only to your self. I beg you not to disclose it till i come over because I am affraid of my wicked uncle who has threatened to kill me.
Sincerely yours,
Miss Sofia Justin Yak
^ permalink raw reply
* Re: [PATCH] kdump: Fix crash_kexec - smp_send_stop race in panic
From: Michael Holzheu @ 2011-10-31 9:57 UTC (permalink / raw)
To: Andrew Morton
Cc: heiko.carstens, kexec, linux-kernel, Eric W. Biederman,
schwidefsky, Vivek Goyal
In-Reply-To: <20111028161143.e5ebf617.akpm@linux-foundation.org>
Hello Andrew,
On Fri, 2011-10-28 at 16:11 -0700, Andrew Morton wrote:
[snip]
> Should this be done earlier in the function? As it stands we'll have
> multiple CPUs scribbling on buf[] at the same time and all trying to
> print the same thing at the same time, dumping their stacks, etc.
> Perhaps it would be better to single-thread all that stuff
My fist patch took the spinlock at the beginning of panic(). But then
Eric asked, if it wouldn't be better to get both panic printk's and I
agreed.
> Also... this patch affects all CPU architectures, all configs, etc.
> So we're expecting that every architecture's smp_send_stop() is able to
> stop a CPU which is spinning in spin_lock(), possibly with local
> interrupts disabled. Will this work?
At least on s390 it will work. If there are architectures that can't
stop disabled CPUs then this problem is already there without this
patch.
Example:
1. 1st CPU gets lock X and panics
2. 2nd CPU is disabled and gets lock X
3. 1st CPU calls smp_send_stop()
-> 2nd CPU loops disabled and can't be stopped
Michael
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH] kdump: Fix crash_kexec - smp_send_stop race in panic
From: Michael Holzheu @ 2011-10-31 9:57 UTC (permalink / raw)
To: Andrew Morton
Cc: heiko.carstens, kexec, linux-kernel, Eric W. Biederman,
schwidefsky, Vivek Goyal
In-Reply-To: <20111028161143.e5ebf617.akpm@linux-foundation.org>
Hello Andrew,
On Fri, 2011-10-28 at 16:11 -0700, Andrew Morton wrote:
[snip]
> Should this be done earlier in the function? As it stands we'll have
> multiple CPUs scribbling on buf[] at the same time and all trying to
> print the same thing at the same time, dumping their stacks, etc.
> Perhaps it would be better to single-thread all that stuff
My fist patch took the spinlock at the beginning of panic(). But then
Eric asked, if it wouldn't be better to get both panic printk's and I
agreed.
> Also... this patch affects all CPU architectures, all configs, etc.
> So we're expecting that every architecture's smp_send_stop() is able to
> stop a CPU which is spinning in spin_lock(), possibly with local
> interrupts disabled. Will this work?
At least on s390 it will work. If there are architectures that can't
stop disabled CPUs then this problem is already there without this
patch.
Example:
1. 1st CPU gets lock X and panics
2. 2nd CPU is disabled and gets lock X
3. 1st CPU calls smp_send_stop()
-> 2nd CPU loops disabled and can't be stopped
Michael
^ permalink raw reply
* [PATCH 5/5] ath6kl: cut power during suspend
From: Kalle Valo @ 2011-10-31 9:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20111031095550.3598.52653.stgit@localhost6.localdomain6>
If sdio controller doesn't support keep power, cut power from hardware
during suspend and restart firmware during resume. If we are connected
during suspend, send a disconnected event to user space.
Earlier suspend failed with an error if sdio didn't support keep power.
Now suspend will happen succesfully even with that case.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 31 ++++++++++++++
drivers/net/wireless/ath/ath6kl/cfg80211.h | 1
drivers/net/wireless/ath/ath6kl/core.h | 1
drivers/net/wireless/ath/ath6kl/debug.h | 1
drivers/net/wireless/ath/ath6kl/sdio.c | 64 +++++++++++++++++++++++++---
5 files changed, 90 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 53aa3be..ef2f210 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -1674,6 +1674,28 @@ int ath6kl_cfg80211_suspend(struct ath6kl *ar,
ar->state = ATH6KL_STATE_DEEPSLEEP;
break;
+
+ case ATH6KL_CFG_SUSPEND_CUTPOWER:
+ if (ar->state == ATH6KL_STATE_OFF) {
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND,
+ "suspend hw off, no action for cutpower\n");
+ break;
+ }
+
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND, "suspend cutting power\n");
+
+ ret = ath6kl_init_hw_stop(ar);
+ if (ret) {
+ ath6kl_warn("failed to stop hw during suspend: %d\n",
+ ret);
+ }
+
+ ar->state = ATH6KL_STATE_CUTPOWER;
+
+ break;
+
+ default:
+ break;
}
return 0;
@@ -1698,6 +1720,15 @@ int ath6kl_cfg80211_resume(struct ath6kl *ar)
break;
+ case ATH6KL_STATE_CUTPOWER:
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND, "resume restoring power\n");
+
+ ret = ath6kl_init_hw_start(ar);
+ if (ret) {
+ ath6kl_warn("Failed to boot hw in resume: %d\n", ret);
+ return ret;
+ }
+
default:
break;
}
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.h b/drivers/net/wireless/ath/ath6kl/cfg80211.h
index 3630c5e..72eadf8 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.h
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.h
@@ -19,6 +19,7 @@
enum ath6kl_cfg_suspend_mode {
ATH6KL_CFG_SUSPEND_DEEPSLEEP,
+ ATH6KL_CFG_SUSPEND_CUTPOWER,
};
struct net_device *ath6kl_interface_add(struct ath6kl *ar, char *name,
diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index 6613248..f301c32 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -454,6 +454,7 @@ enum ath6kl_state {
ATH6KL_STATE_OFF,
ATH6KL_STATE_ON,
ATH6KL_STATE_DEEPSLEEP,
+ ATH6KL_STATE_CUTPOWER,
};
struct ath6kl {
diff --git a/drivers/net/wireless/ath/ath6kl/debug.h b/drivers/net/wireless/ath/ath6kl/debug.h
index 491485e..c24d120 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.h
+++ b/drivers/net/wireless/ath/ath6kl/debug.h
@@ -40,6 +40,7 @@ enum ATH6K_DEBUG_MASK {
ATH6KL_DBG_SDIO_DUMP = BIT(17),
ATH6KL_DBG_BOOT = BIT(18), /* driver init and fw boot */
ATH6KL_DBG_WMI_DUMP = BIT(19),
+ ATH6KL_DBG_SUSPEND = BIT(20),
ATH6KL_DBG_ANY = 0xffffffff /* enable all logs */
};
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index d718926..e66d18b 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -742,12 +742,11 @@ static int ath6kl_sdio_suspend(struct ath6kl *ar)
flags = sdio_get_host_pm_caps(func);
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND, "sdio suspend pm_caps 0x%x\n", flags);
+
if (!(flags & MMC_PM_KEEP_POWER)) {
- /* as host doesn't support keep power we need to bail out */
- ath6kl_dbg(ATH6KL_DBG_SDIO,
- "func %d doesn't support MMC_PM_KEEP_POWER\n",
- func->num);
- return -EINVAL;
+ /* as host doesn't support keep power we need to cut power */
+ return ath6kl_cfg80211_suspend(ar, ATH6KL_CFG_SUSPEND_CUTPOWER);
}
ret = sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
@@ -757,13 +756,30 @@ static int ath6kl_sdio_suspend(struct ath6kl *ar)
return ret;
}
- ath6kl_cfg80211_suspend(ar, ATH6KL_CFG_SUSPEND_DEEPSLEEP);
-
- return 0;
+ return ath6kl_cfg80211_suspend(ar, ATH6KL_CFG_SUSPEND_DEEPSLEEP);
}
static int ath6kl_sdio_resume(struct ath6kl *ar)
{
+ struct ath6kl_sdio *ar_sdio = ath6kl_sdio_priv(ar);
+ struct sdio_func *func = ar_sdio->func;
+ int ret;
+
+ if (ar->state == ATH6KL_STATE_CUTPOWER) {
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND,
+ "sdio resume configuring sdio\n");
+
+ sdio_claim_host(func);
+ func->enable_timeout = 100;
+ ret = sdio_set_block_size(func, HIF_MBOX_BLOCK_SIZE);
+ if (ret) {
+ ath6kl_err("Set sdio block size %d failed: %d)\n",
+ HIF_MBOX_BLOCK_SIZE, ret);
+ }
+
+ sdio_release_host(func);
+ }
+
ath6kl_cfg80211_resume(ar);
return 0;
@@ -818,6 +834,37 @@ static const struct ath6kl_hif_ops ath6kl_sdio_ops = {
.stop = ath6kl_sdio_stop,
};
+#ifdef CONFIG_PM_SLEEP
+
+/*
+ * Empty handlers so that mmc subsystem doesn't remove us entirely during
+ * suspend. We instead follow cfg80211 suspend/resume handlers.
+ */
+static int ath6kl_sdio_pm_suspend(struct device *device)
+{
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND, "sdio pm suspend\n");
+
+ return 0;
+}
+
+static int ath6kl_sdio_pm_resume(struct device *device)
+{
+ ath6kl_dbg(ATH6KL_DBG_SUSPEND, "sdio pm resume\n");
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(ath6kl_sdio_pm_ops, ath6kl_sdio_pm_suspend,
+ ath6kl_sdio_pm_resume);
+
+#define ATH6KL_SDIO_PM_OPS (&ath6kl_sdio_pm_ops)
+
+#else
+
+#define ATH6KL_SDIO_PM_OPS NULL
+
+#endif /* CONFIG_PM_SLEEP */
+
static int ath6kl_sdio_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
@@ -958,6 +1005,7 @@ static struct sdio_driver ath6kl_sdio_driver = {
.id_table = ath6kl_sdio_devices,
.probe = ath6kl_sdio_probe,
.remove = ath6kl_sdio_remove,
+ .drv.pm = ATH6KL_SDIO_PM_OPS,
};
static int __init ath6kl_sdio_init(void)
^ permalink raw reply related
* [PATCH 4/5] ath6kl: add state variable depicting hw/fw state
From: Kalle Valo @ 2011-10-31 9:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20111031095550.3598.52653.stgit@localhost6.localdomain6>
This way it's easier to track state changes and in the future add
more warnings about using hardware in wrong states. Currently there
are few random flags for trying to do the same, those will be cleaned
and removed in the future.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 28 +++++++++++++++++++++++-----
drivers/net/wireless/ath/ath6kl/core.h | 9 +++++++++
drivers/net/wireless/ath/ath6kl/init.c | 4 ++++
3 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 0691a95..53aa3be 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -1671,6 +1671,8 @@ int ath6kl_cfg80211_suspend(struct ath6kl *ar,
ret);
}
+ ar->state = ATH6KL_STATE_DEEPSLEEP;
+
break;
}
@@ -1679,11 +1681,25 @@ int ath6kl_cfg80211_suspend(struct ath6kl *ar,
int ath6kl_cfg80211_resume(struct ath6kl *ar)
{
- if (ar->wmi->pwr_mode != ar->wmi->saved_pwr_mode) {
- if (ath6kl_wmi_powermode_cmd(ar->wmi, 0,
- ar->wmi->saved_pwr_mode) != 0)
- ath6kl_warn("ath6kl_sdio_resume: "
- "wmi_powermode_cmd failed\n");
+ int ret;
+
+ switch (ar->state) {
+ case ATH6KL_STATE_DEEPSLEEP:
+ if (ar->wmi->pwr_mode != ar->wmi->saved_pwr_mode) {
+ ret = ath6kl_wmi_powermode_cmd(ar->wmi, 0,
+ ar->wmi->saved_pwr_mode);
+ if (ret) {
+ ath6kl_warn("wmi powermode command failed during resume: %d\n",
+ ret);
+ }
+ }
+
+ ar->state = ATH6KL_STATE_ON;
+
+ break;
+
+ default:
+ break;
}
return 0;
@@ -2251,6 +2267,8 @@ struct ath6kl *ath6kl_core_alloc(struct device *dev)
ar->sc_params.scan_ctrl_flags = DEFAULT_SCAN_CTRL_FLAGS;
ar->lrssi_roam_threshold = DEF_LRSSI_ROAM_THRESHOLD;
+ ar->state = ATH6KL_STATE_OFF;
+
memset((u8 *)ar->sta_list, 0,
AP_MAX_NUM_STA * sizeof(struct ath6kl_sta));
diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index 00cc1db..6613248 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -450,9 +450,18 @@ enum ath6kl_dev_state {
FIRST_BOOT,
};
+enum ath6kl_state {
+ ATH6KL_STATE_OFF,
+ ATH6KL_STATE_ON,
+ ATH6KL_STATE_DEEPSLEEP,
+};
+
struct ath6kl {
struct device *dev;
struct wiphy *wiphy;
+
+ enum ath6kl_state state;
+
struct ath6kl_bmi bmi;
const struct ath6kl_hif_ops *hif_ops;
struct wmi *wmi;
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 06e5cea..f7fcd91 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1452,6 +1452,8 @@ int ath6kl_init_hw_start(struct ath6kl *ar)
goto err_htc_stop;
}
+ ar->state = ATH6KL_STATE_ON;
+
return 0;
err_htc_stop:
@@ -1480,6 +1482,8 @@ int ath6kl_init_hw_stop(struct ath6kl *ar)
if (ret)
ath6kl_warn("failed to power off hif: %d\n", ret);
+ ar->state = ATH6KL_STATE_OFF;
+
return 0;
}
^ permalink raw reply related
* Re: [PATCH 6/7] ath6kl: Perform WOW resume in RX path in case of SDIO IRQ wakeup
From: Raja Mani @ 2011-10-31 9:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <4EAAABB8.3030309@qca.qualcomm.com>
On Friday 28 October 2011 06:48 PM, Kalle Valo wrote:
> On 10/25/2011 01:37 PM, rmani@qca.qualcomm.com wrote:
>> From: Raja Mani<rmani@qca.qualcomm.com>
>>
>> Signed-off-by: Raja Mani<rmani@qca.qualcomm.com>
>
> Empty commit log.
I'll add commit message here..
>
>> --- a/drivers/net/wireless/ath/ath6kl/txrx.c
>> +++ b/drivers/net/wireless/ath/ath6kl/txrx.c
>> @@ -1081,6 +1081,8 @@ void ath6kl_rx(struct htc_target *target, struct htc_packet *packet)
>> return;
>> }
>>
>> + ath6kl_pm_check_wow_status(ar);
>
> Now we resume from two places, cfg80211 resume handler and here. Why do
> we need to do that? Why isn't cfg80211 resume handler enough?
This path hits when the target wants to wake up the host. When given WOW
pattern matches, the target will pull SDIO data line to wake up the
host. During that time , the control will reach here (sdio irq handler
-> ath6kl_rx function), not to cfg80211 resume.
>
> Kalle
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.