From zamek42 at gmail.com  Wed Jun  1 03:25:49 2011
From: zamek42 at gmail.com (zamek42)
Date: Wed, 01 Jun 2011 09:25:49 +0200
Subject: Freescale i.mx25 SDIO/Libertas issue
In-Reply-To: <4DE44F16.8050407@bluewatersys.com>
References: <4DE2F84D.8080907@bluewatersys.com>
	<4DE44F16.8050407@bluewatersys.com>
Message-ID: <4DE5E97D.90705@gmail.com>

hello,

05/31/2011 04:14 AM keltez?ssel, Andre Renaud ?rta:
> If I enable the libertas debugging details, I get some more information:
>
> This seems to imply that the unit is correctly loading the firmware, and
> then when it determines that the firmware has loaded, and tries to issue
> the CMD_FUNC_INIT command, this times out.
>
> Can anyone explain how I can begin debugging this, or confirm if they've
> had this operate on the sdhci-esdhc-imx controller present in the i.MX25?
>
I got same errors with 2.6.31 kernel. As I suggested earlier use 2.6.35 
from Freescale.

git clone http://opensource.freescale.com/pub/scm/imx/linux-2.6-imx.git
cd linux-2.6-imx
git checkout rel_imx_2.6.35_11.04.01
copy .config from your 2.6.31
make ARCH=arm oldconfig
make ARCH=arm menuconfig

It works for me well.
Is your wifi card hard wired or plugined?

-- 
thx
Zoltan (Zamek) Zidarics
programmer
email:zamek42 at gmail.com
skype:zamek_z



From andre at bluewatersys.com  Wed Jun  1 18:41:02 2011
From: andre at bluewatersys.com (Andre Renaud)
Date: Thu, 02 Jun 2011 10:41:02 +1200
Subject: [Solved] Re: Freescale i.mx25 SDIO/Libertas issue
In-Reply-To: <4DE5E97D.90705@gmail.com>
References: <4DE2F84D.8080907@bluewatersys.com>	<4DE44F16.8050407@bluewatersys.com>
	<4DE5E97D.90705@gmail.com>
Message-ID: <4DE6BFFE.6000101@bluewatersys.com>

Hello Zamek,

> 05/31/2011 04:14 AM keltez?ssel, Andre Renaud ?rta:
>> If I enable the libertas debugging details, I get some more information:
>>
>> This seems to imply that the unit is correctly loading the firmware, and
>> then when it determines that the firmware has loaded, and tries to issue
>> the CMD_FUNC_INIT command, this times out.
>>
>> Can anyone explain how I can begin debugging this, or confirm if they've
>> had this operate on the sdhci-esdhc-imx controller present in the i.MX25?
>>
> I got same errors with 2.6.31 kernel. As I suggested earlier use 2.6.35
> from Freescale.
> 
> git clone http://opensource.freescale.com/pub/scm/imx/linux-2.6-imx.git
> cd linux-2.6-imx
> git checkout rel_imx_2.6.35_11.04.01
> copy .config from your 2.6.31
> make ARCH=arm oldconfig
> make ARCH=arm menuconfig
> 
> It works for me well.
> Is your wifi card hard wired or plugined?
> 

Thanks for that information - using that kernel branch I have had it all
working properly, on both an 8686 and 8688 Marvell SDIO device. These
are both external (plugged in).

I was hoping to do a git bisect to determine where the fault lay,
however it seems that the imx tree uses a completely different SDIO
driver. I have validated the Libertas driver on a different CPU (atmel)
from the same kernel, so I'm assuming at this stage that the fault lies
in the SDIO driver in the current Linux mainline.

Regards,
Andre

-- 
Bluewater Systems - An Aiotec Company

Andre Renaud        		
andre at bluewatersys.com          5 Amuri Park, 404 Barbadoes St
www.bluewatersys.com            PO Box 13 889, Christchurch 8013
www.aiotec.co.nz                New Zealand
Phone: +64 3 3779127            Freecall: Australia 1800 148 751
Fax:   +64 3 3779135            USA 1800 261 2934


From sharon_burns72 at gmail.com  Thu Jun  2 04:13:52 2011
From: sharon_burns72 at gmail.com (Sharon.Burns)
Date: Thu, 02 Jun 2011 03:13:52 -0500
Subject: Hello Would You Like To Earn
Message-ID: <E1QS32O-001Q8v-Lw@host113.kvchosting.com>

Hello libertas-dev

Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself.

visit->http:tinyurl.com/3brnlpx

Regards,

Sharon Burns

Survey Human Resources Dept.




From zamek42 at gmail.com  Thu Jun  2 05:14:33 2011
From: zamek42 at gmail.com (zamek42)
Date: Thu, 02 Jun 2011 11:14:33 +0200
Subject: [Solved] Re: Freescale i.mx25 SDIO/Libertas issue
In-Reply-To: <4DE6BFFE.6000101@bluewatersys.com>
References: <4DE2F84D.8080907@bluewatersys.com>	<4DE44F16.8050407@bluewatersys.com>	<4DE5E97D.90705@gmail.com>
	<4DE6BFFE.6000101@bluewatersys.com>
Message-ID: <4DE75479.7080701@gmail.com>

hello,

06/02/2011 12:41 AM keltez?ssel, Andre Renaud ?rta:
>
> Thanks for that information - using that kernel branch I have had it all
> working properly, on both an 8686 and 8688 Marvell SDIO device. These
> are both external (plugged in).
>
Its a good news... :)
> I was hoping to do a git bisect to determine where the fault lay,
I think so bisect cannot found anything, because it used for found a 
mistake on a previously working source code.
But sdio is not worked on 2.6.31 and becomes good on 2.6.35.

> however it seems that the imx tree uses a completely different SDIO
> driver. I have validated the Libertas driver on a different CPU (atmel)
> from the same kernel, so I'm assuming at this stage that the fault lies
> in the SDIO driver in the current Linux mainline.
>
Yes, unfortunately Freesacle has an own kernel tree, and cannot works 
with vanilla kernel.

-- 
thx
Zoltan (Zamek) Zidarics
programmer
email:zamek42 at gmail.com
skype:zamek_z



From dsd at laptop.org  Thu Jun  2 19:13:26 2011
From: dsd at laptop.org (Daniel Drake)
Date: Fri,  3 Jun 2011 00:13:26 +0100 (BST)
Subject: [PATCH] libertas_sdio: handle spurious interrupts
Message-ID: <20110602231327.116A79D401C@zog.reactivated.net>

Commit 06e8935febe687e2a561707d4c7ca4245d261dbe adds an IRQ handling
optimization for single-function SDIO cards like this one, but at the
same time exposes a small hardware bug.

During hardware init, an interrupt is generated with (apparently) no
source. Previously, mmc threw this interrupt away, but now (due to the
optimization), the mmc layer passes this onto libertas, before it is ready
(and before it has enabled interrupts), causing a crash.

Work around this hardware bug by registering the IRQ handler later and
making it capable of handling interrupts with no cause. The change that
makes the IRQ handler registration happen later actually eliminates
the spurious interrupt as well.

Signed-off-by: Daniel Drake <dsd at laptop.org>
---
 drivers/net/wireless/libertas/if_sdio.c |   21 ++++++++++++++++-----
 1 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index a7b5cb0..224e985 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -907,7 +907,7 @@ static void if_sdio_interrupt(struct sdio_func *func)
 	card = sdio_get_drvdata(func);
 
 	cause = sdio_readb(card->func, IF_SDIO_H_INT_STATUS, &ret);
-	if (ret)
+	if (ret || !cause)
 		goto out;
 
 	lbs_deb_sdio("interrupt: 0x%X\n", (unsigned)cause);
@@ -1008,10 +1008,6 @@ static int if_sdio_probe(struct sdio_func *func,
 	if (ret)
 		goto release;
 
-	ret = sdio_claim_irq(func, if_sdio_interrupt);
-	if (ret)
-		goto disable;
-
 	/* For 1-bit transfers to the 8686 model, we need to enable the
 	 * interrupt flag in the CCCR register. Set the MMC_QUIRK_LENIENT_FN0
 	 * bit to allow access to non-vendor registers. */
@@ -1083,6 +1079,21 @@ static int if_sdio_probe(struct sdio_func *func,
 		card->rx_unit = 0;
 
 	/*
+	 * Set up the interrupt handler late.
+	 *
+	 * If we set it up earlier, the (buggy) hardware generates a spurious
+	 * interrupt, even before the interrupt has been enabled, with
+	 * CCCR_INTx = 0.
+	 *
+	 * We register the interrupt handler late so that we can handle any
+	 * spurious interrupts, and also to avoid generation of that known
+	 * spurious interrupt in the first place.
+	 */
+	ret = sdio_claim_irq(func, if_sdio_interrupt);
+	if (ret)
+		goto disable;
+
+	/*
 	 * Enable interrupts now that everything is set up
 	 */
 	sdio_writeb(func, 0x0f, IF_SDIO_H_INT_MASK, &ret);
-- 
1.7.5.2



From dcbw at redhat.com  Fri Jun  3 15:20:20 2011
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 03 Jun 2011 14:20:20 -0500
Subject: [PATCH] libertas_sdio: handle spurious interrupts
In-Reply-To: <20110602231327.116A79D401C@zog.reactivated.net>
References: <20110602231327.116A79D401C@zog.reactivated.net>
Message-ID: <1307128821.23945.18.camel@dcbw.foobar.com>

On Fri, 2011-06-03 at 00:13 +0100, Daniel Drake wrote:
> Commit 06e8935febe687e2a561707d4c7ca4245d261dbe adds an IRQ handling
> optimization for single-function SDIO cards like this one, but at the
> same time exposes a small hardware bug.
> 
> During hardware init, an interrupt is generated with (apparently) no
> source. Previously, mmc threw this interrupt away, but now (due to the
> optimization), the mmc layer passes this onto libertas, before it is ready
> (and before it has enabled interrupts), causing a crash.
> 
> Work around this hardware bug by registering the IRQ handler later and
> making it capable of handling interrupts with no cause. The change that
> makes the IRQ handler registration happen later actually eliminates
> the spurious interrupt as well.
> 
> Signed-off-by: Daniel Drake <dsd at laptop.org>

Acked-by: Dan Williams <dcbw at redhat.com>

> ---
>  drivers/net/wireless/libertas/if_sdio.c |   21 ++++++++++++++++-----
>  1 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
> index a7b5cb0..224e985 100644
> --- a/drivers/net/wireless/libertas/if_sdio.c
> +++ b/drivers/net/wireless/libertas/if_sdio.c
> @@ -907,7 +907,7 @@ static void if_sdio_interrupt(struct sdio_func *func)
>  	card = sdio_get_drvdata(func);
>  
>  	cause = sdio_readb(card->func, IF_SDIO_H_INT_STATUS, &ret);
> -	if (ret)
> +	if (ret || !cause)
>  		goto out;
>  
>  	lbs_deb_sdio("interrupt: 0x%X\n", (unsigned)cause);
> @@ -1008,10 +1008,6 @@ static int if_sdio_probe(struct sdio_func *func,
>  	if (ret)
>  		goto release;
>  
> -	ret = sdio_claim_irq(func, if_sdio_interrupt);
> -	if (ret)
> -		goto disable;
> -
>  	/* For 1-bit transfers to the 8686 model, we need to enable the
>  	 * interrupt flag in the CCCR register. Set the MMC_QUIRK_LENIENT_FN0
>  	 * bit to allow access to non-vendor registers. */
> @@ -1083,6 +1079,21 @@ static int if_sdio_probe(struct sdio_func *func,
>  		card->rx_unit = 0;
>  
>  	/*
> +	 * Set up the interrupt handler late.
> +	 *
> +	 * If we set it up earlier, the (buggy) hardware generates a spurious
> +	 * interrupt, even before the interrupt has been enabled, with
> +	 * CCCR_INTx = 0.
> +	 *
> +	 * We register the interrupt handler late so that we can handle any
> +	 * spurious interrupts, and also to avoid generation of that known
> +	 * spurious interrupt in the first place.
> +	 */
> +	ret = sdio_claim_irq(func, if_sdio_interrupt);
> +	if (ret)
> +		goto disable;
> +
> +	/*
>  	 * Enable interrupts now that everything is set up
>  	 */
>  	sdio_writeb(func, 0x0f, IF_SDIO_H_INT_MASK, &ret);




From zonque at gmail.com  Mon Jun  6 09:17:05 2011
From: zonque at gmail.com (Daniel Mack)
Date: Mon, 6 Jun 2011 15:17:05 +0200
Subject: [PATCH v5] sdio: optimized SDIO IRQ handling for single irq
In-Reply-To: <m31v052nle.fsf@pullcord.laptop.org>
References: <1305128885-21275-1-git-send-email-per.forlin@linaro.org>
	<1305128885-21275-2-git-send-email-per.forlin@linaro.org>
	<m31v052nle.fsf@pullcord.laptop.org>
Message-ID: <BANLkTincsU5=RvrA91Vy3bpSyGfzCvfF-A@mail.gmail.com>

On Wed, May 11, 2011 at 6:45 PM, Chris Ball <cjb at laptop.org> wrote:
> Hi Per,
>
> On Wed, May 11 2011, Per Forlin wrote:
>> From: Stefan Nilsson XK <stefan.xk.nilsson at stericsson.com>
>>
>> If there is only 1 function interrupt registered it is possible to
>> improve performance by directly calling the irq handler
>> and avoiding the overhead of reading the CCCR registers.
>>
>> Signed-off-by: Per Forlin <per.forlin at linaro.org>
>> Acked-by: Ulf Hansson <ulf.hansson at stericsson.com>
>> Reviewed-by: Nicolas Pitre <nicolas.pitre at linaro.org>
>> ---
>> ?drivers/mmc/core/sdio_irq.c | ? 33 ++++++++++++++++++++++++++++++++-
>> ?include/linux/mmc/card.h ? ?| ? ?1 +
>> ?2 files changed, 33 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
>> index bb192f9..a0890ac 100644
>> --- a/drivers/mmc/core/sdio_irq.c
>> +++ b/drivers/mmc/core/sdio_irq.c
>> @@ -31,6 +31,17 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
>> ?{
>> ? ? ? int i, ret, count;
>> ? ? ? unsigned char pending;
>> + ? ? struct sdio_func *func;
>> +
>> + ? ? /*
>> + ? ? ?* Optimization, if there is only 1 function interrupt registered
>> + ? ? ?* call irq handler directly
>> + ? ? ?*/
>> + ? ? func = card->sdio_single_irq;
>> + ? ? if (func) {
>> + ? ? ? ? ? ? func->irq_handler(func);
>> + ? ? ? ? ? ? return 1;
>> + ? ? }
>>
>> ? ? ? ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
>> ? ? ? if (ret) {
>> @@ -42,7 +53,7 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
>> ? ? ? count = 0;
>> ? ? ? for (i = 1; i <= 7; i++) {
>> ? ? ? ? ? ? ? if (pending & (1 << i)) {
>> - ? ? ? ? ? ? ? ? ? ? struct sdio_func *func = card->sdio_func[i - 1];
>> + ? ? ? ? ? ? ? ? ? ? func = card->sdio_func[i - 1];
>> ? ? ? ? ? ? ? ? ? ? ? if (!func) {
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? printk(KERN_WARNING "%s: pending IRQ for "
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "non-existant function\n",
>> @@ -186,6 +197,24 @@ static int sdio_card_irq_put(struct mmc_card *card)
>> ? ? ? return 0;
>> ?}
>>
>> +/* If there is only 1 function registered set sdio_single_irq */
>> +static void sdio_single_irq_set(struct mmc_card *card)
>> +{
>> + ? ? struct sdio_func *func;
>> + ? ? int i;
>> +
>> + ? ? card->sdio_single_irq = NULL;
>> + ? ? if ((card->host->caps & MMC_CAP_SDIO_IRQ) &&
>> + ? ? ? ? card->host->sdio_irqs == 1)
>> + ? ? ? ? ? ? for (i = 0; i < card->sdio_funcs; i++) {
>> + ? ? ? ? ? ? ? ? ? ?func = card->sdio_func[i];
>> + ? ? ? ? ? ? ? ? ? ?if (func && func->irq_handler) {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?card->sdio_single_irq = func;
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
>> + ? ? ? ? ? ? ? ? ? ?}
>> + ? ? ? ? ? ?}
>> +}
>> +
>> ?/**
>> ? * ? sdio_claim_irq - claim the IRQ for a SDIO function
>> ? * ? @func: SDIO function
>> @@ -227,6 +256,7 @@ int sdio_claim_irq(struct sdio_func *func, sdio_irq_handler_t *handler)
>> ? ? ? ret = sdio_card_irq_get(func->card);
>> ? ? ? if (ret)
>> ? ? ? ? ? ? ? func->irq_handler = NULL;
>> + ? ? sdio_single_irq_set(func->card);
>>
>> ? ? ? return ret;
>> ?}
>> @@ -251,6 +281,7 @@ int sdio_release_irq(struct sdio_func *func)
>> ? ? ? if (func->irq_handler) {
>> ? ? ? ? ? ? ? func->irq_handler = NULL;
>> ? ? ? ? ? ? ? sdio_card_irq_put(func->card);
>> + ? ? ? ? ? ? sdio_single_irq_set(func->card);
>> ? ? ? }
>>
>> ? ? ? ret = mmc_io_rw_direct(func->card, 0, 0, SDIO_CCCR_IENx, 0, &reg);
>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>> index d8dffc9..4910dec 100644
>> --- a/include/linux/mmc/card.h
>> +++ b/include/linux/mmc/card.h
>> @@ -191,6 +191,7 @@ struct mmc_card {
>> ? ? ? struct sdio_cccr ? ? ? ?cccr; ? ? ? ? ? /* common card info */
>> ? ? ? struct sdio_cis ? ? ? ? cis; ? ? ? ? ? ?/* common tuple info */
>> ? ? ? struct sdio_func ? ? ? ?*sdio_func[SDIO_MAX_FUNCS]; /* SDIO functions (devices) */
>> + ? ? struct sdio_func ? ? ? ?*sdio_single_irq; /* SDIO function when only one IRQ active */
>> ? ? ? unsigned ? ? ? ? ? ? ? ?num_info; ? ? ? /* number of info strings */
>> ? ? ? const char ? ? ? ? ? ? ?**info; ? ? ? ? /* info strings */
>> ? ? ? struct sdio_func_tuple ?*tuples; ? ? ? ?/* unknown common tuples */
>
> Thanks, looks good now -- pushed to mmc-next for .40.

This patch breaks libertas over SDIO, as the interrupt handler of that
driver is now called even though the hardware didn't signal any
interrupt condition. This is a problem for at least two reasons in
this case:

a) the libertas code is currently structured in a way that it calls
sdio_claim_irq() before everything is fully set up (which wasn't a
problem so far as the hardware has an own register to mask
interrupts). That results in a kernel Ooops as card->priv == NULL.

b) the libertas interrupt handler assumes that a received callback to
its interrupt handler signals activity per se
("card->priv->activty_detected = 1").


I have a patch ready for libertas that works around the first problem,
but I'm unsure if that's not fixing the wrong end. What the driver
really should do is poll the card's CCCR register to find out if there
was any interrupt at all and bail if that's not the case, but then
we're back to the implementation without this patch.

The other option is to revert the patch again.

Any suggestions?

Daniel


From zonque at gmail.com  Mon Jun  6 09:22:48 2011
From: zonque at gmail.com (Daniel Mack)
Date: Mon, 6 Jun 2011 15:22:48 +0200
Subject: [PATCH v5] sdio: optimized SDIO IRQ handling for single irq
In-Reply-To: <BANLkTincsU5=RvrA91Vy3bpSyGfzCvfF-A@mail.gmail.com>
References: <1305128885-21275-1-git-send-email-per.forlin@linaro.org>
	<1305128885-21275-2-git-send-email-per.forlin@linaro.org>
	<m31v052nle.fsf@pullcord.laptop.org>
	<BANLkTincsU5=RvrA91Vy3bpSyGfzCvfF-A@mail.gmail.com>
Message-ID: <BANLkTi=umBJyi9CDu47UxhvA3vERmx7c-A@mail.gmail.com>

On Mon, Jun 6, 2011 at 3:17 PM, Daniel Mack <zonque at gmail.com> wrote:
> On Wed, May 11, 2011 at 6:45 PM, Chris Ball <cjb at laptop.org> wrote:
>> Hi Per,
>>
>> On Wed, May 11 2011, Per Forlin wrote:
>>> From: Stefan Nilsson XK <stefan.xk.nilsson at stericsson.com>
>>>
>>> If there is only 1 function interrupt registered it is possible to
>>> improve performance by directly calling the irq handler
>>> and avoiding the overhead of reading the CCCR registers.
>>>
>>> Signed-off-by: Per Forlin <per.forlin at linaro.org>
>>> Acked-by: Ulf Hansson <ulf.hansson at stericsson.com>
>>> Reviewed-by: Nicolas Pitre <nicolas.pitre at linaro.org>
>>> ---
>>> ?drivers/mmc/core/sdio_irq.c | ? 33 ++++++++++++++++++++++++++++++++-
>>> ?include/linux/mmc/card.h ? ?| ? ?1 +
>>> ?2 files changed, 33 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
>>> index bb192f9..a0890ac 100644
>>> --- a/drivers/mmc/core/sdio_irq.c
>>> +++ b/drivers/mmc/core/sdio_irq.c
>>> @@ -31,6 +31,17 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
>>> ?{
>>> ? ? ? int i, ret, count;
>>> ? ? ? unsigned char pending;
>>> + ? ? struct sdio_func *func;
>>> +
>>> + ? ? /*
>>> + ? ? ?* Optimization, if there is only 1 function interrupt registered
>>> + ? ? ?* call irq handler directly
>>> + ? ? ?*/
>>> + ? ? func = card->sdio_single_irq;
>>> + ? ? if (func) {
>>> + ? ? ? ? ? ? func->irq_handler(func);
>>> + ? ? ? ? ? ? return 1;
>>> + ? ? }
>>>
>>> ? ? ? ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
>>> ? ? ? if (ret) {
>>> @@ -42,7 +53,7 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
>>> ? ? ? count = 0;
>>> ? ? ? for (i = 1; i <= 7; i++) {
>>> ? ? ? ? ? ? ? if (pending & (1 << i)) {
>>> - ? ? ? ? ? ? ? ? ? ? struct sdio_func *func = card->sdio_func[i - 1];
>>> + ? ? ? ? ? ? ? ? ? ? func = card->sdio_func[i - 1];
>>> ? ? ? ? ? ? ? ? ? ? ? if (!func) {
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? printk(KERN_WARNING "%s: pending IRQ for "
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "non-existant function\n",
>>> @@ -186,6 +197,24 @@ static int sdio_card_irq_put(struct mmc_card *card)
>>> ? ? ? return 0;
>>> ?}
>>>
>>> +/* If there is only 1 function registered set sdio_single_irq */
>>> +static void sdio_single_irq_set(struct mmc_card *card)
>>> +{
>>> + ? ? struct sdio_func *func;
>>> + ? ? int i;
>>> +
>>> + ? ? card->sdio_single_irq = NULL;
>>> + ? ? if ((card->host->caps & MMC_CAP_SDIO_IRQ) &&
>>> + ? ? ? ? card->host->sdio_irqs == 1)
>>> + ? ? ? ? ? ? for (i = 0; i < card->sdio_funcs; i++) {
>>> + ? ? ? ? ? ? ? ? ? ?func = card->sdio_func[i];
>>> + ? ? ? ? ? ? ? ? ? ?if (func && func->irq_handler) {
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?card->sdio_single_irq = func;
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
>>> + ? ? ? ? ? ? ? ? ? ?}
>>> + ? ? ? ? ? ?}
>>> +}
>>> +
>>> ?/**
>>> ? * ? sdio_claim_irq - claim the IRQ for a SDIO function
>>> ? * ? @func: SDIO function
>>> @@ -227,6 +256,7 @@ int sdio_claim_irq(struct sdio_func *func, sdio_irq_handler_t *handler)
>>> ? ? ? ret = sdio_card_irq_get(func->card);
>>> ? ? ? if (ret)
>>> ? ? ? ? ? ? ? func->irq_handler = NULL;
>>> + ? ? sdio_single_irq_set(func->card);
>>>
>>> ? ? ? return ret;
>>> ?}
>>> @@ -251,6 +281,7 @@ int sdio_release_irq(struct sdio_func *func)
>>> ? ? ? if (func->irq_handler) {
>>> ? ? ? ? ? ? ? func->irq_handler = NULL;
>>> ? ? ? ? ? ? ? sdio_card_irq_put(func->card);
>>> + ? ? ? ? ? ? sdio_single_irq_set(func->card);
>>> ? ? ? }
>>>
>>> ? ? ? ret = mmc_io_rw_direct(func->card, 0, 0, SDIO_CCCR_IENx, 0, &reg);
>>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>>> index d8dffc9..4910dec 100644
>>> --- a/include/linux/mmc/card.h
>>> +++ b/include/linux/mmc/card.h
>>> @@ -191,6 +191,7 @@ struct mmc_card {
>>> ? ? ? struct sdio_cccr ? ? ? ?cccr; ? ? ? ? ? /* common card info */
>>> ? ? ? struct sdio_cis ? ? ? ? cis; ? ? ? ? ? ?/* common tuple info */
>>> ? ? ? struct sdio_func ? ? ? ?*sdio_func[SDIO_MAX_FUNCS]; /* SDIO functions (devices) */
>>> + ? ? struct sdio_func ? ? ? ?*sdio_single_irq; /* SDIO function when only one IRQ active */
>>> ? ? ? unsigned ? ? ? ? ? ? ? ?num_info; ? ? ? /* number of info strings */
>>> ? ? ? const char ? ? ? ? ? ? ?**info; ? ? ? ? /* info strings */
>>> ? ? ? struct sdio_func_tuple ?*tuples; ? ? ? ?/* unknown common tuples */
>>
>> Thanks, looks good now -- pushed to mmc-next for .40.
>
> This patch breaks libertas over SDIO, as the interrupt handler of that
> driver is now called even though the hardware didn't signal any
> interrupt condition. This is a problem for at least two reasons in
> this case:

I checked the libertas-dev archives too late and saw that there is a
fix by Daniel Drake for this problem already.

Sorry for the noise.

Daniel


From dsd at laptop.org  Tue Jun  7 13:15:57 2011
From: dsd at laptop.org (Daniel Drake)
Date: Tue,  7 Jun 2011 18:15:57 +0100 (BST)
Subject: [PATCH] libertas: add sd8686 reset_card support
Message-ID: <20110607171557.7F65D9D401C@zog.reactivated.net>

At http://dev.laptop.org/ticket/10748 we are seeing a case of the
libertas firmware randomly stopping responding to commands after
resume. Careful monitoring of communications indicates a firmware or
hardware bug, which has been reported to Marvell.

Work around this issue by adding a reset_card method; this is
automatically called when command timeouts are detected and provides an
instant recovery to this situation.

Signed-off-by: Daniel Drake <dsd at laptop.org>
---
 drivers/net/wireless/libertas/if_sdio.c |   34 +++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

linux-mmc: any comments on this? is there a better way to do it?
We do want a full card reset where everything is properly removed and
re-probed, so that userspace knows to reprogram wifi security keys,
re-establish connections, etc.

diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index a7b5cb0..13c9dbe 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -892,6 +892,37 @@ static int if_sdio_reset_deep_sleep_wakeup(struct lbs_private *priv)
 
 }
 
+static struct mmc_host *reset_host;
+
+static void if_sdio_reset_card_worker(struct work_struct *work)
+{
+	/*
+	 * The actual reset operation must be run outside of lbs_thread. This
+	 * is because mmc_remove_host() will cause the device to be instantly
+	 * destroyed, and the libertas driver then needs to end lbs_thread,
+	 * leading to a deadlock.
+	 *
+	 * We run it in a workqueue totally independent from the if_sdio_card
+	 * instance for that reason.
+	 */
+
+	lbs_pr_info("Resetting card...");
+	mmc_remove_host(reset_host);
+	mmc_add_host(reset_host);
+}
+static DECLARE_WORK(card_reset_work, if_sdio_reset_card_worker);
+
+static void if_sdio_reset_card(struct lbs_private *priv)
+{
+	struct if_sdio_card *card = priv->card;
+
+	if (work_pending(&card_reset_work))
+		return;
+
+	reset_host = card->func->card->host;
+	schedule_work(&card_reset_work);
+}
+
 /*******************************************************************/
 /* SDIO callbacks                                                  */
 /*******************************************************************/
@@ -1069,6 +1100,7 @@ static int if_sdio_probe(struct sdio_func *func,
 	priv->enter_deep_sleep = if_sdio_enter_deep_sleep;
 	priv->exit_deep_sleep = if_sdio_exit_deep_sleep;
 	priv->reset_deep_sleep_wakeup = if_sdio_reset_deep_sleep_wakeup;
+	priv->reset_card = if_sdio_reset_card;
 
 	sdio_claim_host(func);
 
@@ -1290,6 +1322,8 @@ static void __exit if_sdio_exit_module(void)
 	/* Set the flag as user is removing this module. */
 	user_rmmod = 1;
 
+	cancel_work_sync(&card_reset_work);
+
 	sdio_unregister_driver(&if_sdio_driver);
 
 	lbs_deb_leave(LBS_DEB_SDIO);
-- 
1.7.5.2



From nikanth at google.com  Fri Jun 10 04:57:02 2011
From: nikanth at google.com (Nikanth Karthikesan)
Date: Fri, 10 Jun 2011 14:27:02 +0530
Subject: [PATCH][TRIVIAL] if_spi: Fix compilation warning - unused variable
Message-ID: <1307696222.28682.20.camel@nikanth.blr.corp.google.com>

if_spi: Fix compilation warning - unused variable

drivers/net/wireless/libertas/if_spi.c: In function ?if_spi_init_card?:
drivers/net/wireless/libertas/if_spi.c:1035: warning: unused variable ?spi?

Signed-off-by: Nikanth Karthikesan <nikanth at google.com>

---

Index: linux-2.6/drivers/net/wireless/libertas/if_spi.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/libertas/if_spi.c	2011-06-10 11:44:29.900986193 +0530
+++ linux-2.6/drivers/net/wireless/libertas/if_spi.c	2011-06-10 11:45:07.830985403 +0530
@@ -1066,7 +1066,7 @@
 			goto out;
 		}
 
-		err = lbs_get_firmware(&card->spi->dev, NULL, NULL,
+		err = lbs_get_firmware(&spi->dev, NULL, NULL,
 					card->card_id, &fw_table[0], &helper,
 					&mainfw);
 		if (err) {




From sebastian.priebe at konplan.com  Fri Jun 10 04:51:35 2011
From: sebastian.priebe at konplan.com (Sebastian Priebe)
Date: Fri, 10 Jun 2011 10:51:35 +0200
Subject: kernel panic on power off
Message-ID: <OF71322DB4.2CCF4389-ONC12578AB.003094D9-C12578AB.0030C6B3@konplan.com>

Hi,
we are using an AmbiCom CF card for WLAN on an MX1 powered board with 
Kernel 2.6.36.3.

In our PCMCIA driver we power down the CF card 2 seconds after the eject 
request if the card is still powered on.
In this case we get an kernel panic. We don't have the option to wait any 
longer for power down.
Can someone tell me, why the driver is still sending commands after we 
stopped the card?

Here is the log of the kernel panic:
 
pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0
pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 82)
libertas: 00:10:7a:74:39:b0, fw 5.0.16p0, cap 0x00000393
lbs_update_hw_spec: regioncode: 1040
lbs_cfg_set_regulatory_hint: regioncode: 40
cfg80211: Calling CRDA for country: JP
libertas: wlan0: Marvell WLAN 802.11 adapter
pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0
libertas: PREP_CMD: command 0x0006 failed: -2
------------[ cut here ]------------
WARNING: at net/wireless/core.c:638 wdev_cleanup_work+0x5c/0xf8()
Modules linked in:
Backtrace:
[<c0025304>] (dump_backtrace+0x0/0x10c) from [<c0271bb0>] 
(dump_stack+0x18/0x1c)
 r7:00000000 r6:c02549d4 r5:c0307a19 r4:0000027e
[<c0271b98>] (dump_stack+0x0/0x1c) from [<c0032b68>] 
(warn_slowpath_common+0x54/0x6c)
[<c0032b14>] (warn_slowpath_common+0x0/0x6c) from [<c0032ba4>] 
(warn_slowpath_null+0x24/0x2c)
 r8:c1847e00 r7:c194e628 r6:c198c0c0 r5:c198c000 r4:c198c00c
[<c0032b80>] (warn_slowpath_null+0x0/0x2c) from [<c02549d4>] 
(wdev_cleanup_work+0x5c/0xf8)
[<c0254978>] (wdev_cleanup_work+0x0/0xf8) from [<c0044414>] 
(process_one_work+0x250/0x3ac)
 r7:0000001a r6:0000001b r5:c1802240 r4:c194e628
[<c00441c4>] (process_one_work+0x0/0x3ac) from [<c00450b8>] 
(worker_thread+0x210/0x424)
[<c0044ea8>] (worker_thread+0x0/0x424) from [<c0049a08>] 
(kthread+0x88/0x90)
[<c0049980>] (kthread+0x0/0x90) from [<c0035f1c>] (do_exit+0x0/0x5a0)
 r7:00000013 r6:c0035f1c r5:c0049980 r4:c181bf04
---[ end trace 657895c8dce08edd ]---
libertas: Received CMD_RESP with invalid sequence 9 (expected 0)
Error while ejecting - force power off
libertas_cs: card data buffer has invalid # of bytes (0)
Unhandled fault: external abort on non-linefetch (0x80a) at 0xc287e000
Internal error: : 80a [#1]
last sysfs file: /sys/devices/platform/mx1_hbp_cf/cf_on
Modules linked in:
CPU: 0    Tainted: G        W    (2.6.36.3 #59)
PC is at if_cs_interrupt+0x22c/0x624
LR is at release_console_sem+0x1b0/0x214
pc : [<c01b26f4>]    lr : [<c0033518>]    psr: 60000093
sp : c19bfdb4  ip : c19bfcf4  fp : c19bfde8
r10: 00000552  r9 : c19783a0  r8 : c198c220
r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : c1989280
r3 : c287e000  r2 : 00000002  r1 : 00001e58  r0 : 0000003f
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: c000717f  Table: 099c4000  DAC: 00000015
Process sh (pid: 323, stack limit = 0xc19be270)
Stack: (0xc19bfdb4 to 0xc19c0000)
fda0:                                              ffffe1e4 c19bfde4 
c19bfdc8
fdc0: c1989280 00000000 00000000 00000052 00000040 c1989418 c19bff78 
c19bfe08
fde0: c19bfdec c005ef90 c01b24d8 c0329acc 00000052 c0324ef8 00040000 
c19bfe20
fe00: c19bfe0c c0060d30 c005ef74 00000052 00040000 c19bfe48 c19bfe24 
c002c468
fe20: c0060ca4 c03264a0 0000000b 00000000 000b0000 c0324d68 c0286d24 
c19bfe60
fe40: c19bfe4c c0021078 c002c368 ffffffff f4023000 c19bfebc c19bfe64 
c0021aac
fe60: c0021010 00000001 0000001e 00000001 54400000 60000013 0000007e 
00000001
fe80: c0324d68 c0286d24 c1989418 c19bff78 c19bfebc f401c300 c19bfeac 
c0149908
fea0: c002c144 60000013 ffffffff c032501c c19bfedc c19bfec0 c0149908 
c002c120
fec0: c19bff04 00000014 c190a400 00000002 c19bff04 c19bfee0 c01bb974 
c01498cc
fee0: c1989418 00000000 c19bff04 c194c960 00000002 c1989400 c19bff14 
c19bff08
ff00: c0164620 c01bb8a4 c19bff44 c19bff18 c00c9aa4 c0164608 c0035cf0 
c191ec00
ff20: 00000002 401c47b4 c19bff78 c0021fc4 c19be000 00000000 c19bff74 
c19bff48
ff40: c0087b94 c00c99a4 c0035dcc c0046834 00000003 00000000 00000000 
c191ec00
ff60: 00000004 c0021fc4 c19bffa4 c19bff78 c0087ce8 c0087aec 00000000 
00000000
ff80: c0093e30 00000000 00000002 401c12f4 00000002 401c47b4 00000000 
c19bffa8
ffa0: c0021e40 c0087cac 401c12f4 00000002 00000001 401c47b4 00000002 
401c47b6
ffc0: 401c12f4 00000002 401c47b4 00000004 00000001 00081008 00000000 
00081284
ffe0: 0007ea0c bea1f6a8 4018fc44 4017efdc 20000010 00000001 00000000 
00000000
Backtrace:
[<c01b24c8>] (if_cs_interrupt+0x0/0x624) from [<c005ef90>] 
(handle_IRQ_event+0x2c/0xf8)
[<c005ef64>] (handle_IRQ_event+0x0/0xf8) from [<c0060d30>] 
(handle_level_irq+0x9c/0x108)
 r7:00040000 r6:c0324ef8 r5:00000052 r4:c0329acc
[<c0060c94>] (handle_level_irq+0x0/0x108) from [<c002c468>] 
(mx3_gpio_irq_handler+0x110/0x124)
 r5:00040000 r4:00000052
[<c002c358>] (mx3_gpio_irq_handler+0x0/0x124) from [<c0021078>] 
(asm_do_IRQ+0x78/0x9c)
 r8:c0286d24 r7:c0324d68 r6:000b0000 r5:00000000 r4:0000000b
[<c0021000>] (asm_do_IRQ+0x0/0x9c) from [<c0021aac>] (__irq_svc+0x2c/0x60)
Exception stack(0xc19bfe64 to 0xc19bfeac)
fe60:          00000001 0000001e 00000001 54400000 60000013 0000007e 
00000001
fe80: c0324d68 c0286d24 c1989418 c19bff78 c19bfebc f401c300 c19bfeac 
c0149908
fea0: c002c144 60000013 ffffffff
 r5:f4023000 r4:ffffffff
[<c002c110>] (mxc_gpio_set+0x0/0x38) from [<c0149908>] 
(__gpio_set_value+0x4c/0x5c)
 r4:c032501c
[<c01498bc>] (__gpio_set_value+0x0/0x5c) from [<c01bb974>] 
(mx1_hbp_cf_on_store+0xe0/0xfc)
 r6:00000002 r5:c190a400 r4:00000014
[<c01bb894>] (mx1_hbp_cf_on_store+0x0/0xfc) from [<c0164620>] 
(dev_attr_store+0x28/0x2c)
 r6:c1989400 r5:00000002 r4:c194c960
[<c01645f8>] (dev_attr_store+0x0/0x2c) from [<c00c9aa4>] 
(sysfs_write_file+0x110/0x148)
[<c00c9994>] (sysfs_write_file+0x0/0x148) from [<c0087b94>] 
(vfs_write+0xb8/0x144)
[<c0087adc>] (vfs_write+0x0/0x144) from [<c0087ce8>] (sys_write+0x4c/0x7c)
 r8:c0021fc4 r7:00000004 r6:c191ec00 r5:00000000 r4:00000000
[<c0087c9c>] (sys_write+0x0/0x7c) from [<c0021e40>] 
(ret_fast_syscall+0x0/0x2c)
 r6:401c47b4 r5:00000002 r4:401c12f4
Code: 15423001 e59831b0 e3a02002 e5933008 (e1c320b0)
---[ end trace dce08ededce08edd ]---
Kernel panic - not syncing: Fatal exception in interrupt
Backtrace:
[<c0025304>] (dump_backtrace+0x0/0x10c) from [<c0271bb0>] 
(dump_stack+0x18/0x1c)
 r7:c19bfd6c r6:c19be000 r5:c19508a0 r4:00000000
[<c0271b98>] (dump_stack+0x0/0x1c) from [<c0271c04>] (panic+0x50/0x188)
[<c0271bb4>] (panic+0x0/0x188) from [<c0025728>] (die+0x188/0x1c8)
 r3:00010000 r2:c02e04b9 r1:00000000 r0:c02da0be
[<c00255a0>] (die+0x0/0x1c8) from [<c0025830>] (arm_notify_die+0x58/0x5c)
[<c00257d8>] (arm_notify_die+0x0/0x5c) from [<c0021314>] 
(do_DataAbort+0x88/0x9c)
[<c002128c>] (do_DataAbort+0x0/0x9c) from [<c0021a60>] 
(__dabt_svc+0x40/0x60)
Exception stack(0xc19bfd6c to 0xc19bfdb4)
fd60:                            0000003f 00001e58 00000002 c287e000 
c1989280
fd80: 00000000 00000000 00000000 c198c220 c19783a0 00000552 c19bfde8 
c19bfcf4
fda0: c19bfdb4 c0033518 c01b26f4 60000093 ffffffff
 r8:c198c220 r7:00000000 r6:00000000 r5:c19bfda0 r4:ffffffff
[<c01b24c8>] (if_cs_interrupt+0x0/0x624) from [<c005ef90>] 
(handle_IRQ_event+0x2c/0xf8)
[<c005ef64>] (handle_IRQ_event+0x0/0xf8) from [<c0060d30>] 
(handle_level_irq+0x9c/0x108)
 r7:00040000 r6:c0324ef8 r5:00000052 r4:c0329acc
[<c0060c94>] (handle_level_irq+0x0/0x108) from [<c002c468>] 
(mx3_gpio_irq_handler+0x110/0x124)
 r5:00040000 r4:00000052
[<c002c358>] (mx3_gpio_irq_handler+0x0/0x124) from [<c0021078>] 
(asm_do_IRQ+0x78/0x9c)
 r8:c0286d24 r7:c0324d68 r6:000b0000 r5:00000000 r4:0000000b
[<c0021000>] (asm_do_IRQ+0x0/0x9c) from [<c0021aac>] (__irq_svc+0x2c/0x60)
Exception stack(0xc19bfe64 to 0xc19bfeac)
fe60:          00000001 0000001e 00000001 54400000 60000013 0000007e 
00000001
fe80: c0324d68 c0286d24 c1989418 c19bff78 c19bfebc f401c300 c19bfeac 
c0149908
fea0: c002c144 60000013 ffffffff
 r5:f4023000 r4:ffffffff
[<c002c110>] (mxc_gpio_set+0x0/0x38) from [<c0149908>] 
(__gpio_set_value+0x4c/0x5c)
 r4:c032501c
[<c01498bc>] (__gpio_set_value+0x0/0x5c) from [<c01bb974>] 
(mx1_hbp_cf_on_store+0xe0/0xfc)
 r6:00000002 r5:c190a400 r4:00000014
[<c01bb894>] (mx1_hbp_cf_on_store+0x0/0xfc) from [<c0164620>] 
(dev_attr_store+0x28/0x2c)
 r6:c1989400 r5:00000002 r4:c194c960
[<c01645f8>] (dev_attr_store+0x0/0x2c) from [<c00c9aa4>] 
(sysfs_write_file+0x110/0x148)
[<c00c9994>] (sysfs_write_file+0x0/0x148) from [<c0087b94>] 
(vfs_write+0xb8/0x144)
[<c0087adc>] (vfs_write+0x0/0x144) from [<c0087ce8>] (sys_write+0x4c/0x7c)
 r8:c0021fc4 r7:00000004 r6:c191ec00 r5:00000000 r4:00000000
[<c0087c9c>] (sys_write+0x0/0x7c) from [<c0021e40>] 
(ret_fast_syscall+0x0/0x2c)
 r6:401c47b4 r5:00000002 r4:401c12f4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20110610/cae10df0/attachment-0001.html>

From leif at leifzars.com  Sun Jun 12 10:34:22 2011
From: leif at leifzars.com (Leif Zars)
Date: Sun, 12 Jun 2011 09:34:22 -0500
Subject: Version
Message-ID: <026e01cc290d$d572b580$80582080$@com>

I would like to download the most up-to-date version of this driver, were
would I get it?

 

Thanks

 

Leif

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20110612/83a09274/attachment-0001.html>

From dcbw at redhat.com  Mon Jun 13 11:01:55 2011
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 13 Jun 2011 10:01:55 -0500
Subject: Version
In-Reply-To: <026e01cc290d$d572b580$80582080$@com>
References: <026e01cc290d$d572b580$80582080$@com>
Message-ID: <1307977315.2117.8.camel@dcbw.foobar.com>

On Sun, 2011-06-12 at 09:34 -0500, Leif Zars wrote:
> I would like to download the most up-to-date version of this driver,
> were would I get it?

It's always in the latest Linux kernel.

Dan




From nikanth at google.com  Tue Jun 14 01:53:46 2011
From: nikanth at google.com (Nikanth Karthikesan)
Date: Tue, 14 Jun 2011 11:23:46 +0530
Subject: [PATCH][TRIVIAL] if_spi: Fix compilation warning - unused variable
In-Reply-To: <1307976362.2117.4.camel@dcbw.foobar.com>
References: <1307696222.28682.20.camel@nikanth.blr.corp.google.com>
	<1307976362.2117.4.camel@dcbw.foobar.com>
Message-ID: <1308030827.28682.32.camel@nikanth.blr.corp.google.com>

if_spi: Fix compilation warning - unused variable 'spi'

drivers/net/wireless/libertas/if_spi.c: In function ?if_spi_init_card?:
drivers/net/wireless/libertas/if_spi.c:1035: warning: unused variable ?spi?

The variable is used only in a macro which uses the args only for DEBUG builds.
Remove the 'spi' variable completely.

Signed-off-by: Nikanth Karthikesan <nikanth at google.com>

---

Index: linux-2.6/drivers/net/wireless/libertas/if_spi.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/libertas/if_spi.c	2011-06-10 14:16:17.990985032 +0530
+++ linux-2.6/drivers/net/wireless/libertas/if_spi.c	2011-06-14 09:33:16.151025614 +0530
@@ -1032,7 +1032,6 @@
 static int if_spi_init_card(struct if_spi_card *card)
 {
 	struct lbs_private *priv = card->priv;
-	struct spi_device *spi = card->spi;
 	int err, i;
 	u32 scratch;
 	const struct firmware *helper = NULL;
@@ -1080,8 +1079,9 @@
 				"attached to SPI bus_num %d, chip_select %d. "
 				"spi->max_speed_hz=%d\n",
 				card->card_id, card->card_rev,
-				spi->master->bus_num, spi->chip_select,
-				spi->max_speed_hz);
+				card->spi->master->bus_num,
+				card->spi->chip_select,
+				card->spi->max_speed_hz);
 		err = if_spi_prog_helper_firmware(card, helper);
 		if (err)
 			goto out;




From dcbw at redhat.com  Tue Jun 14 22:33:54 2011
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 14 Jun 2011 21:33:54 -0500
Subject: [PATCH][TRIVIAL] if_spi: Fix compilation warning - unused variable
In-Reply-To: <1308030827.28682.32.camel@nikanth.blr.corp.google.com>
References: <1307696222.28682.20.camel@nikanth.blr.corp.google.com>
	<1307976362.2117.4.camel@dcbw.foobar.com>
	<1308030827.28682.32.camel@nikanth.blr.corp.google.com>
Message-ID: <1308105236.6398.5.camel@dcbw.foobar.com>

On Tue, 2011-06-14 at 11:23 +0530, Nikanth Karthikesan wrote:
> if_spi: Fix compilation warning - unused variable 'spi'
> 
> drivers/net/wireless/libertas/if_spi.c: In function ?if_spi_init_card?:
> drivers/net/wireless/libertas/if_spi.c:1035: warning: unused variable ?spi?
> 
> The variable is used only in a macro which uses the args only for DEBUG builds.
> Remove the 'spi' variable completely.
> 
> Signed-off-by: Nikanth Karthikesan <nikanth at google.com>

Acked-by: Dan Williams <dcbw at redhat.com>

> 
> ---
> 
> Index: linux-2.6/drivers/net/wireless/libertas/if_spi.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/libertas/if_spi.c	2011-06-10 14:16:17.990985032 +0530
> +++ linux-2.6/drivers/net/wireless/libertas/if_spi.c	2011-06-14 09:33:16.151025614 +0530
> @@ -1032,7 +1032,6 @@
>  static int if_spi_init_card(struct if_spi_card *card)
>  {
>  	struct lbs_private *priv = card->priv;
> -	struct spi_device *spi = card->spi;
>  	int err, i;
>  	u32 scratch;
>  	const struct firmware *helper = NULL;
> @@ -1080,8 +1079,9 @@
>  				"attached to SPI bus_num %d, chip_select %d. "
>  				"spi->max_speed_hz=%d\n",
>  				card->card_id, card->card_rev,
> -				spi->master->bus_num, spi->chip_select,
> -				spi->max_speed_hz);
> +				card->spi->master->bus_num,
> +				card->spi->chip_select,
> +				card->spi->max_speed_hz);
>  		err = if_spi_prog_helper_firmware(card, helper);
>  		if (err)
>  			goto out;
> 
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev




From GChriss at openvideo.pro  Thu Jun 16 19:08:36 2011
From: GChriss at openvideo.pro (George Chriss)
Date: Thu, 16 Jun 2011 19:08:36 -0400 (EDT)
Subject: libertas on ETRAX FS / Elphel 353?
Message-ID: <40525.74.64.51.206.1308265716.squirrel@openvideo.pro>

Hi,

I'm interested in hacking the libertas driver to run on an Axis ETRAX FS
with a heavily-patched 2.6.19 kernel.[1]

It's a discontinued CPU and also a big jump from the >= 2.6.24 kernels
supported by compat-wireless.  However, support for this target would mean
that wireless CompactFlash cards[2] could be used to broadcast live
audio/video wirelessly from Elphel cameras[3].  Current Elphel models are
limited to USB 1.1 (too slow for video) and the only other option that
comes to mind is attaching a wireless router to the Ethernet port.  Newer
Elphel models are unlikely to be released in the near future and it would
take a lot of development effort to update the kernel in current models.

Is libertas support for this embedded system feasible?  I attempted to
build compat-wireless against the Elphel kernel sources and successfully
generated a long list of errors with 'make --keep-going' after commenting
out unnecessary parts of the Makefile.  The build log may be found at [4].


Sincerely,
George


[1] Running code on the ETRAX FS CPU requires use of gcc-cris.
[2] Such as the AmbiCom WL54CF, which powers up and fits nicely into the
Elphel NC353L-369
[3] http://www.elphel.com/353_turnkey
[4] http://is.gd/zFczww



From proski at gnu.org  Fri Jun 17 10:46:19 2011
From: proski at gnu.org (Pavel Roskin)
Date: Fri, 17 Jun 2011 10:46:19 -0400
Subject: libertas on ETRAX FS / Elphel 353?
In-Reply-To: <40525.74.64.51.206.1308265716.squirrel@openvideo.pro>
References: <40525.74.64.51.206.1308265716.squirrel@openvideo.pro>
Message-ID: <4DFB68BB.5070902@gnu.org>

On 06/16/2011 07:08 PM, George Chriss wrote:

> Is libertas support for this embedded system feasible?  I attempted to
> build compat-wireless against the Elphel kernel sources and successfully
> generated a long list of errors with 'make --keep-going' after commenting
> out unnecessary parts of the Makefile.  The build log may be found at [4].

If it's a one-off effort for one driver, I think it should be possible. 
  MadWifi (current snapshots) supports kernels from 2.4.22 to 3.0, and 
the compatibility layer is not very thick.

Many errors in that log come from the compatibility code you are not 
going to need, such as MSI support.

INIT_WORK changes are tricky, but it should be easier to backport the 
code than it was to forward port it.  MadWifi could be used as a reference.

You probably don't want mesh support.  Try disabling as all the code 
that can be disabled.

I don't know how intrusive USB changes have been.  Basically, until you 
try, there is no way to tell how hard it might be.

compat-wireless didn't go to older kernels because it needs to be 
constantly maintained and because it supports multiple drivers.

-- 
Regards,
Pavel Roskin


From dilinger at queued.net  Sun Jun 19 00:38:03 2011
From: dilinger at queued.net (Andres Salomon)
Date: Sat, 18 Jun 2011 21:38:03 -0700
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
Message-ID: <20110618213803.521db1b3@debxo>

The following changes since commit 97649b1e5449029c845ebf7500e780a8867c3e89:

  linux-firmware: Add a new FW 7.0.20.0 (2011-06-15 11:38:11 +0100)

are available in the git repository at:
  git://lunge.queued.net/git/linux-firmware master

Andres Salomon (1):
      libertas: add OLPC libertas blobs

 LICENCE.OLPC                 |   33 +++++++++++++++++++++++++++++++++
 WHENCE                       |   20 ++++++++++++++++++++
 libertas/lbtf_sdio.bin       |  Bin 0 -> 120924 bytes
 libertas/lbtf_usb.bin        |  Bin 0 -> 118888 bytes
 libertas/sd8686_v9_OLPC.bin  |  Bin 0 -> 124244 bytes
 libertas/usb8388_v5_OLPC.bin |  Bin 0 -> 127824 bytes
 6 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100644 LICENCE.OLPC
 create mode 100644 libertas/lbtf_sdio.bin
 create mode 100644 libertas/lbtf_usb.bin
 create mode 100644 libertas/sd8686_v9_OLPC.bin
 create mode 100644 libertas/usb8388_v5_OLPC.bin


From dilinger at queued.net  Sun Jun 19 00:42:03 2011
From: dilinger at queued.net (Andres Salomon)
Date: Sat, 18 Jun 2011 21:42:03 -0700
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <20110618213803.521db1b3@debxo>
References: <20110618213803.521db1b3@debxo>
Message-ID: <20110618214203.0028ba85@debxo>

On Sat, 18 Jun 2011 21:38:03 -0700
Andres Salomon <dilinger at queued.net> wrote:

> The following changes since commit
> 97649b1e5449029c845ebf7500e780a8867c3e89:
> 
>   linux-firmware: Add a new FW 7.0.20.0 (2011-06-15 11:38:11 +0100)
> 
> are available in the git repository at:
>   git://lunge.queued.net/git/linux-firmware master
> 
> Andres Salomon (1):
>       libertas: add OLPC libertas blobs
> 
>  LICENCE.OLPC                 |   33 +++++++++++++++++++++++++++++++++
>  WHENCE                       |   20 ++++++++++++++++++++
>  libertas/lbtf_sdio.bin       |  Bin 0 -> 120924 bytes
>  libertas/lbtf_usb.bin        |  Bin 0 -> 118888 bytes
>  libertas/sd8686_v9_OLPC.bin  |  Bin 0 -> 124244 bytes
>  libertas/usb8388_v5_OLPC.bin |  Bin 0 -> 127824 bytes

Of course, if people would prefer the OLPC version to supersede the
ones currently in the linux-firmware tree, I can do that instead.  I
don't know what versions of sd8686.bin and usb8388.bin are actually in
the tree.  I also don't know if the OLPC versions improve or make things
worse for people using those chips on non-OLPC systems.


From dilinger at queued.net  Sun Jun 19 00:51:07 2011
From: dilinger at queued.net (Andres Salomon)
Date: Sat, 18 Jun 2011 21:51:07 -0700
Subject: [PATCH linux-firmware] libertas: add OLPC libertas blobs
In-Reply-To: <20110618213803.521db1b3@debxo>
References: <20110618213803.521db1b3@debxo>
Message-ID: <20110618215107.692747d4@debxo>

These blobs are released by the OLPC project, and drive Marvell
libertas chips.  OLPC hardware has additional features and quirks,
which makes special firmware necessary.

The firmware was downloaded from
http://dev.laptop.org/pub/firmware/libertas/.

Signed-off-by: Andres Salomon <dilinger at lunge.queued.net>
---
 LICENCE.OLPC                 |   33 +++++++++++++++++++++++++++++++++
 WHENCE                       |   20 ++++++++++++++++++++
 libertas/lbtf_sdio.bin       |  Bin 0 -> 120924 bytes
 libertas/lbtf_usb.bin        |  Bin 0 -> 118888 bytes
 libertas/sd8686_v9_OLPC.bin  |  Bin 0 -> 124244 bytes
 libertas/usb8388_v5_OLPC.bin |  Bin 0 -> 127824 bytes
 6 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100644 LICENCE.OLPC
 create mode 100644 libertas/lbtf_sdio.bin
 create mode 100644 libertas/lbtf_usb.bin
 create mode 100644 libertas/sd8686_v9_OLPC.bin
 create mode 100644 libertas/usb8388_v5_OLPC.bin

diff --git a/LICENCE.OLPC b/LICENCE.OLPC
new file mode 100644
index 0000000..a740952
--- /dev/null
+++ b/LICENCE.OLPC
@@ -0,0 +1,33 @@
+Copyright (c) 2006, One Laptop per Child and Marvell Corporation.
+All rights reserved.
+
+Redistribution.  Redistribution and use in binary form, without 
+modification, are permitted provided that the following conditions are 
+met:
+
+* Redistributions must reproduce the above copyright notice and the 
+  following disclaimer in the documentation and/or other materials 
+  provided with the distribution.
+* Neither the name of Marvell Corporation nor the names of its suppliers 
+  may be used to endorse or promote products derived from this software 
+  without specific prior written permission.
+* No reverse engineering, decompilation, or disassembly of this software 
+  is permitted.
+* You may not use or attempt to use this software in conjunction with
+  any product that is offered by a third party as a replacement,
+  substitute or alternative to a Marvell Product where a Marvell Product
+  is defined as a proprietary wireless LAN embedded client solution of
+  Marvell or a Marvell Affiliate.
+
+DISCLAIMER.  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
+CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, 
+BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 
+FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
+COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS 
+OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 
+TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
+USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
+DAMAGE.
diff --git a/WHENCE b/WHENCE
index 4c51b23..f43f347 100644
--- a/WHENCE
+++ b/WHENCE
@@ -644,6 +644,26 @@ Linux driver tarballs downloaded from Marvell's "Extranet" with permission.
 
 --------------------------------------------------------------------------
 
+Driver: libertas - Marvell Libertas 802.11b/g cards, OLPC firmware
+
+File: libertas/lbtf_sdio.bin
+Info: v9.0.7.p4
+
+File: libertas/lbtf_usb.bin
+Info: v5.132.3.p1
+
+File: libertas/sd8686_v9_OLPC.bin
+Info: v9.70.7.p0
+
+File: libertas/usb8388_v5_OLPC.bin
+Info: v5.110.22.p23
+
+Licence: Redistributable. See LICENCE.OLPC for details.
+
+Available from http://dev.laptop.org/pub/firmware/libertas/
+
+--------------------------------------------------------------------------
+
 Driver: mwl8k - Marvell Libertas softmac-type 802.11b/g cards
 
 File: mwl8k/fmimage_8687.fw
diff --git a/libertas/lbtf_sdio.bin b/libertas/lbtf_sdio.bin
new file mode 100644
index 0000000..a93d765
Binary files /dev/null and b/libertas/lbtf_sdio.bin differ
diff --git a/libertas/lbtf_usb.bin b/libertas/lbtf_usb.bin
new file mode 100644
index 0000000..8ee231a
Binary files /dev/null and b/libertas/lbtf_usb.bin differ
diff --git a/libertas/sd8686_v9_OLPC.bin b/libertas/sd8686_v9_OLPC.bin
new file mode 100644
index 0000000..8f877a7
Binary files /dev/null and b/libertas/sd8686_v9_OLPC.bin differ
diff --git a/libertas/usb8388_v5_OLPC.bin b/libertas/usb8388_v5_OLPC.bin
new file mode 100644
index 0000000..e01b6c2
Binary files /dev/null and b/libertas/usb8388_v5_OLPC.bin differ
-- 
1.7.2.5



From dsd at laptop.org  Sun Jun 19 05:41:22 2011
From: dsd at laptop.org (Daniel Drake)
Date: Sun, 19 Jun 2011 10:41:22 +0100
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <20110618214203.0028ba85@debxo>
References: <20110618213803.521db1b3@debxo>
	<20110618214203.0028ba85@debxo>
Message-ID: <BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>

On 19 June 2011 05:42, Andres Salomon <dilinger at queued.net> wrote:
>> ?LICENCE.OLPC ? ? ? ? ? ? ? ? | ? 33 +++++++++++++++++++++++++++++++++
>> ?WHENCE ? ? ? ? ? ? ? ? ? ? ? | ? 20 ++++++++++++++++++++
>> ?libertas/lbtf_sdio.bin ? ? ? | ?Bin 0 -> 120924 bytes
>> ?libertas/lbtf_usb.bin ? ? ? ?| ?Bin 0 -> 118888 bytes
>> ?libertas/sd8686_v9_OLPC.bin ?| ?Bin 0 -> 124244 bytes
>> ?libertas/usb8388_v5_OLPC.bin | ?Bin 0 -> 127824 bytes
>
> Of course, if people would prefer the OLPC version to supersede the
> ones currently in the linux-firmware tree, I can do that instead. ?I
> don't know what versions of sd8686.bin and usb8388.bin are actually in
> the tree. ?I also don't know if the OLPC versions improve or make things
> worse for people using those chips on non-OLPC systems.

This overlaps with a submission I made the other day (of usb8388
firmware), sorry for the lack of coordination there.

I don't think the OLPC hardware has any quirks or special features
that mean it requires special firmware.

However, for the usb8388 we do use a special firmware developed by
Cozybit (not Marvell), the one you submitted, which has its own
versioning scheme. The main difference is that it includes mesh
support. I am pretty sure it would run on any usb8388 but OLPC is the
only user of the hardware anyway. See
http://lists.infradead.org/pipermail/libertas-dev/2010-November/003330.html
and the rest of the discussion.

As for sd8686, I thought our firmware was standard, from Marvell, and
simply a newer version of what is in linux-firmware. Do you have
reason to believe otherwise?

Thanks,
Daniel


From dilinger at queued.net  Sun Jun 19 14:11:27 2011
From: dilinger at queued.net (Andres Salomon)
Date: Sun, 19 Jun 2011 11:11:27 -0700
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
References: <20110618213803.521db1b3@debxo> <20110618214203.0028ba85@debxo>
	<BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
Message-ID: <20110619111127.005064d0@debxo>

On Sun, 19 Jun 2011 10:41:22 +0100
Daniel Drake <dsd at laptop.org> wrote:

> On 19 June 2011 05:42, Andres Salomon <dilinger at queued.net> wrote:
> >> ?LICENCE.OLPC ? ? ? ? ? ? ? ? | ? 33
> >> +++++++++++++++++++++++++++++++++ WHENCE ? ? ? ? ? ? ? ? ? ? ? |
> >> 20 ++++++++++++++++++++ libertas/lbtf_sdio.bin ? ? ? | ?Bin 0 ->
> >> 120924 bytes libertas/lbtf_usb.bin ? ? ? ?| ?Bin 0 -> 118888 bytes
> >> ?libertas/sd8686_v9_OLPC.bin ?| ?Bin 0 -> 124244 bytes
> >> ?libertas/usb8388_v5_OLPC.bin | ?Bin 0 -> 127824 bytes
> >
> > Of course, if people would prefer the OLPC version to supersede the
> > ones currently in the linux-firmware tree, I can do that instead. ?I
> > don't know what versions of sd8686.bin and usb8388.bin are actually
> > in the tree. ?I also don't know if the OLPC versions improve or
> > make things worse for people using those chips on non-OLPC systems.
> 
> This overlaps with a submission I made the other day (of usb8388
> firmware), sorry for the lack of coordination there.

Ah, sorry, I didn't know you were on top of this.  I'm wanting to
kill off the Debian OLPC-specific libertas package, and finally found
some time to put together a pull request.

> 
> I don't think the OLPC hardware has any quirks or special features
> that mean it requires special firmware.
> 
> However, for the usb8388 we do use a special firmware developed by
> Cozybit (not Marvell), the one you submitted, which has its own
> versioning scheme. The main difference is that it includes mesh
> support. I am pretty sure it would run on any usb8388 but OLPC is the
> only user of the hardware anyway. See
> http://lists.infradead.org/pipermail/libertas-dev/2010-November/003330.html
> and the rest of the discussion.
> 
> As for sd8686, I thought our firmware was standard, from Marvell, and
> simply a newer version of what is in linux-firmware. Do you have
> reason to believe otherwise?
> 

I was just playing it safe.  I have changelogs for the usb8388 firmware
releases, but not for sd8686.  I'll defer to you for XO-1.5 stuff.

I'm more interested in the lbtf stuff anyways, as I don't see much use
for the on-chip mesh.


From dcbw at redhat.com  Tue Jun 21 00:47:13 2011
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 20 Jun 2011 23:47:13 -0500
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
References: <20110618213803.521db1b3@debxo> <20110618214203.0028ba85@debxo>
	<BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
Message-ID: <1308631634.31157.7.camel@dcbw.foobar.com>

On Sun, 2011-06-19 at 10:41 +0100, Daniel Drake wrote:
> On 19 June 2011 05:42, Andres Salomon <dilinger at queued.net> wrote:
> >>  LICENCE.OLPC                 |   33 +++++++++++++++++++++++++++++++++
> >>  WHENCE                       |   20 ++++++++++++++++++++
> >>  libertas/lbtf_sdio.bin       |  Bin 0 -> 120924 bytes
> >>  libertas/lbtf_usb.bin        |  Bin 0 -> 118888 bytes
> >>  libertas/sd8686_v9_OLPC.bin  |  Bin 0 -> 124244 bytes
> >>  libertas/usb8388_v5_OLPC.bin |  Bin 0 -> 127824 bytes
> >
> > Of course, if people would prefer the OLPC version to supersede the
> > ones currently in the linux-firmware tree, I can do that instead.  I
> > don't know what versions of sd8686.bin and usb8388.bin are actually in
> > the tree.  I also don't know if the OLPC versions improve or make things
> > worse for people using those chips on non-OLPC systems.
> 
> This overlaps with a submission I made the other day (of usb8388
> firmware), sorry for the lack of coordination there.
> 
> I don't think the OLPC hardware has any quirks or special features
> that mean it requires special firmware.
> 
> However, for the usb8388 we do use a special firmware developed by
> Cozybit (not Marvell), the one you submitted, which has its own
> versioning scheme. The main difference is that it includes mesh
> support. I am pretty sure it would run on any usb8388 but OLPC is the
> only user of the hardware anyway. See
> http://lists.infradead.org/pipermail/libertas-dev/2010-November/003330.html
> and the rest of the discussion.
> 
> As for sd8686, I thought our firmware was standard, from Marvell, and
> simply a newer version of what is in linux-firmware. Do you have
> reason to believe otherwise?

For usb8388 I don't think we really care which firmware is default since
OLPC was about the only consumer of that chip that I've ever heard of.

For the other firmware I periodically trawled Marvell's Extranet and
grabbed latest firmware from there.  If you guys have a newer micro
version of the firmware then great, push it.  Latest I have access to
for 8686 is SD-8686-FEDORA26FC6-SYSKT-9.70.20.p0-26409.p64 so if you've
got something newer great.

Dan




From dilinger at queued.net  Tue Jun 21 03:18:05 2011
From: dilinger at queued.net (Andres Salomon)
Date: Tue, 21 Jun 2011 00:18:05 -0700
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <1308631634.31157.7.camel@dcbw.foobar.com>
References: <20110618213803.521db1b3@debxo> <20110618214203.0028ba85@debxo>
	<BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
	<1308631634.31157.7.camel@dcbw.foobar.com>
Message-ID: <20110621001805.1caecc82@queued.net>

On Mon, 20 Jun 2011 23:47:13 -0500
Dan Williams <dcbw at redhat.com> wrote:

> On Sun, 2011-06-19 at 10:41 +0100, Daniel Drake wrote:
> > On 19 June 2011 05:42, Andres Salomon <dilinger at queued.net> wrote:
> > >>  LICENCE.OLPC                 |   33
> > >> +++++++++++++++++++++++++++++++++ WHENCE
> > >> |   20 ++++++++++++++++++++ libertas/lbtf_sdio.bin       |  Bin
> > >> 0 -> 120924 bytes libertas/lbtf_usb.bin        |  Bin 0 ->
> > >> 118888 bytes libertas/sd8686_v9_OLPC.bin  |  Bin 0 -> 124244
> > >> bytes libertas/usb8388_v5_OLPC.bin |  Bin 0 -> 127824 bytes
> > >
> > > Of course, if people would prefer the OLPC version to supersede
> > > the ones currently in the linux-firmware tree, I can do that
> > > instead.  I don't know what versions of sd8686.bin and
> > > usb8388.bin are actually in the tree.  I also don't know if the
> > > OLPC versions improve or make things worse for people using those
> > > chips on non-OLPC systems.
> > 
> > This overlaps with a submission I made the other day (of usb8388
> > firmware), sorry for the lack of coordination there.
> > 
> > I don't think the OLPC hardware has any quirks or special features
> > that mean it requires special firmware.
> > 
> > However, for the usb8388 we do use a special firmware developed by
> > Cozybit (not Marvell), the one you submitted, which has its own
> > versioning scheme. The main difference is that it includes mesh
> > support. I am pretty sure it would run on any usb8388 but OLPC is
> > the only user of the hardware anyway. See
> > http://lists.infradead.org/pipermail/libertas-dev/2010-November/003330.html
> > and the rest of the discussion.
> > 
> > As for sd8686, I thought our firmware was standard, from Marvell,
> > and simply a newer version of what is in linux-firmware. Do you have
> > reason to believe otherwise?
> 
> For usb8388 I don't think we really care which firmware is default
> since OLPC was about the only consumer of that chip that I've ever
> heard of.
> 
> For the other firmware I periodically trawled Marvell's Extranet and
> grabbed latest firmware from there.  If you guys have a newer micro
> version of the firmware then great, push it.  Latest I have access to
> for 8686 is SD-8686-FEDORA26FC6-SYSKT-9.70.20.p0-26409.p64 so if
> you've got something newer great.


Looks like the one on dev.l.o is older (9.70.7.p0).  Shall I redo the
pull request a) ignoring sd8686, b) replacing usb8388 v5 with the OLPC
version, and c) including both thinfirm blobs as well, then?


From dsd at laptop.org  Tue Jun 21 04:05:33 2011
From: dsd at laptop.org (Daniel Drake)
Date: Tue, 21 Jun 2011 09:05:33 +0100
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <20110621001805.1caecc82@queued.net>
References: <20110618213803.521db1b3@debxo> <20110618214203.0028ba85@debxo>
	<BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
	<1308631634.31157.7.camel@dcbw.foobar.com>
	<20110621001805.1caecc82@queued.net>
Message-ID: <BANLkTi=CPEmFVbwuSBSsQjv4ZqHX+Ng8gw@mail.gmail.com>

On 21 June 2011 08:18, Andres Salomon <dilinger at queued.net> wrote:
> Looks like the one on dev.l.o is older (9.70.7.p0). ?Shall I redo the
> pull request a) ignoring sd8686, b) replacing usb8388 v5 with the OLPC
> version, and c) including both thinfirm blobs as well, then?

That sounds good to me. The only thing I'm a bit unsure about is the
usb8388 thing. If you replace usb8388_v5.bin with the latest OLPC one,
we would like to have that at the top of the list, higher than
usb8388_v9, so that OLPC firmware gets preferred. That might be a bit
strange. On the other hand, if usb8388_olpc_v5.bin is at the top its
less odd, since it looks like a separate branch.

The other changes look fine, and we will figure out sd8686 and send a
later pull request for that. Dan, can you send over
SD-8686-FEDORA26FC6-SYSKT-9.70.20.p0-26409.p64, and any release
notes/changelog you may have? I wasn't aware of this release.

Thanks,
Daniel


From dsd at laptop.org  Thu Jun 23 09:42:17 2011
From: dsd at laptop.org (Daniel Drake)
Date: Thu, 23 Jun 2011 14:42:17 +0100
Subject: [GIT PULL linux-firmware.git] OLPC libertas firmware blobs
In-Reply-To: <BANLkTi=CPEmFVbwuSBSsQjv4ZqHX+Ng8gw@mail.gmail.com>
References: <20110618213803.521db1b3@debxo> <20110618214203.0028ba85@debxo>
	<BANLkTimyFj+iTWAopPMEyohP2pop_=g=6g@mail.gmail.com>
	<1308631634.31157.7.camel@dcbw.foobar.com>
	<20110621001805.1caecc82@queued.net>
	<BANLkTi=CPEmFVbwuSBSsQjv4ZqHX+Ng8gw@mail.gmail.com>
Message-ID: <BANLkTin00W9f40PUjbjgYVRydU7ttJFr9A@mail.gmail.com>

On 21 June 2011 09:05, Daniel Drake <dsd at laptop.org> wrote:
> The other changes look fine, and we will figure out sd8686 and send a
> later pull request for that. Dan, can you send over
> SD-8686-FEDORA26FC6-SYSKT-9.70.20.p0-26409.p64, and any release
> notes/changelog you may have? I wasn't aware of this release.

Also, could you take a look and see if there is some kind of archived
changelog or release history that would link the 3 firmware versions
in question to the same release stream? If it seems obvious that one
follows on from the other it would avoid me having to pester Marvell
about this.

The 3 versions in question are:

1. The version in linux-firmware
$Id: sd8686-B0, RF868X, FP4, 9.70.3.p36 $
RC: , yhou, 2008/09/08, 19:11:06
md5sum: 20208583d441d1ecd7a05d5e5cda5856

2. The OLPC version, shipped in Fedora:
$Id: sd8686-B0, RF868X, FP4, 9.70.7.p0 $
RC: , yhou, 2008/11/11, 13:10:01
md5sum: b4f8be61e19780a14836f146c538c5dd

3. The latest version that you've found
SD-8686-FEDORA26FC6-SYSKT-9.70.20.p0-26409.p64

Thanks,
Daniel


