Hi Stanislaw,
We are doing major driver re-factor works internally, I understand your
patches are important and these patches improve the quality of the
driver. I just wonder if it is ok for you to allow us to merge your
patches into our internal development tree first, then I will push these
patches upstream for you. By doing so, we can make sure your patches can
fully integrated with our on-going driver re-factor work and not cause
any conflict.
Linville, would it be ok for you?
Thanks in advance
Wey
On Thu, 2012-02-23 at 11:16 +0100, Stanislaw Gruszka wrote:
> Print dump stack when the device is not responding. This should give
> some more clue about the reason of failure. Also change the message we
> print, since "MAC in deep sleep" is kinda confusing.
>
> On the way add unlikely(), as fail to gain NIC access is hmm ...
> unlikely.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
> ---
> drivers/net/wireless/iwlwifi/iwl-io.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-io.c b/drivers/net/wireless/iwlwifi/iwl-io.c
> index e2e3b5c..71015a3 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-io.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-io.c
> @@ -121,10 +121,10 @@ int iwl_grab_nic_access_silent(struct iwl_trans *trans)
> int iwl_grab_nic_access(struct iwl_trans *trans)
> {
> int ret = iwl_grab_nic_access_silent(trans);
> - if (ret) {
> + if (unlikely(ret)) {
> u32 val = iwl_read32(trans, CSR_GP_CNTRL);
> - IWL_ERR(trans,
> - "MAC is in deep sleep!. CSR_GP_CNTRL = 0x%08X\n", val);
> + WARN_ONCE(1, "Timeout waiting for ucode processor access "
> + "(CSR_GP_CNTRL 0x%08x)\n", val);
> }
>
> return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
