[PATCH] libertas_sdio lockup fix

[Dan Williams]

On Wed, 2010-03-31 at 15:08 +0200, Jes Sorensen wrote:
> Hi,
> 
> This is a rewamp of an old patch to change the behavior of hot GET_LOG 
> is called within the libertas driver.
> 
> The only reference I have been able to find to the original patch is
> http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html
> According to the posting it was originally written by a James Cameron,
> but I cannot find any email or other reference to the author. Could it
> possibly be Jonathan Cameron?
> 
> Either way, this patch makes the wireless work in my UMID, but I would 
> appreciate it if someone with knowledge of libertas internals could 
> verify I didn't break anything, in particular the sizing of the command 
> sent to get the log.

We're trying to kill lbs_prepare_and_send_command() completely though
and move most commands to separate handlers.  Any chance you could port
the patch to do that instead?  Basically create a function modeled after
cmd.c::lbs_get_tx_power()

int lbs_get_log (struct lbs_private *priv, u32 *retries, u32 *code, u32 *misc)
{
	struct cmd_ds_802_11_get_log cmd;
	int ret;

	lbs_deb_enter(LBS_DEB_CMD);

	memset(&cmd, 0, sizeof(cmd));
	cmd.hdr.size = cpu_to_le16(sizeof(cmd));

	ret = lbs_cmd_with_response(priv, CMD_802_11_GET_LOG, &cmd);
	if (ret == 0) {
		*retries = get_unaligned_le32(cmd.retry);
		*code = get_unaligned_le32(cmd.code);
		*misc = get_unaligned_le32(cmd.misc);
	}

	lbs_deb_leave(LBS_DEB_CMD);
	return ret;
}

Then at the bottom of the function call lbs_get_log() and use the
returned u32 values to populate priv->wstats.  But really, it looks like
the only functional changes here are:

1) the cmd size passed to the 8686 is larger with this patch, since you
haven't removed the header from struct cmd_ds_802_11_get_log; it could
be that we got the size slightly wrong or something when converting it
to a "direct" command?
   - pad the structure in host.h by another u32 at the bottom and see if
this helps

2) calling GET_LOG after RSSI.  Not sure why that would make a
difference, but it could
   - do the "direct" command thing above but move the lbs_get_log() call
after the RSSI call

3) not calling GET_LOG through the blocking command path during the WEXT
stats requests
   - call GET_LOG async and just ignore updating the wstats values to
see if the blocking nature of "direct" commands is indeed the issue
since the wext stats stuff gets called in different places with
different locking semantics

Any chance you could try these three options and see if they also fix
the problem?  I'd like to figure out why this is happing instead of just
apply what looks like a partial revert first.

Thanks!
Dan