All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: johannes.berg@intel.com, luciano.coelho@intel.com,
	emmanuel.grumbach@intel.com
Cc: ming.lei@canonical.com, zajec5@gmail.com, linuxwifi@intel.com,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@kernel.org>
Subject: [PATCH v2 1/2] iwlwifi: fix drv cleanup on opmode registration failure
Date: Tue, 21 Feb 2017 18:09:38 -0800	[thread overview]
Message-ID: <20170222020939.28140-2-mcgrof@kernel.org> (raw)
In-Reply-To: <20170222020939.28140-1-mcgrof@kernel.org>

The firmware async callback handles the device's opmode start
call, but optionally also allows opmode registration to take
care of its opmode start. If the firmware callback handles it
its error path in case of opmode start failure has a few pieces
of code missing from the opmode registration. The opmode
registration hanlder has no cleanup at all. Sync both error
paths.

This should in theory fix a detangled drv from the drv list should
either of the opmode modules loaded and handled registration for the
drv.

The path of having the opmode registration deal with the drv
opmode start is actually the more common path. The other path,
from the async callback is rathe rare (1/8 or so times for me) --
it happens when the the opmode driver's init routine completed
prior to the driver's async callback opmode start call.

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index be466a074c1d..e198d6f5fcea 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const struct iwl_op_mode_ops *ops)
 			continue;
 		op->ops = ops;
 		/* TODO: need to handle exceptional case */
-		list_for_each_entry(drv, &op->drv, list)
+		list_for_each_entry(drv, &op->drv, list) {
 			drv->op_mode = _iwl_op_mode_start(drv, op);
+			if (!drv->op_mode) {
+				complete(&drv->request_firmware_complete);
+				device_release_driver(drv->trans->dev);
+			}
+		}
 
 		mutex_unlock(&iwlwifi_opmode_table_mtx);
 		return 0;
-- 
2.11.0

  reply	other threads:[~2017-02-22  2:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17  2:08 [RFC 0/5] iwlwifi: enhance final opmode work Luis R. Rodriguez
2017-02-17  2:08 ` [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure Luis R. Rodriguez
2017-02-19  9:16   ` Grumbach, Emmanuel
2017-02-20 17:32     ` Luis R. Rodriguez
2017-02-17  2:09 ` [RFC 2/5] iwlwifi: fix request_module() use Luis R. Rodriguez
2017-02-19  9:47   ` Grumbach, Emmanuel
2017-02-21  2:23     ` Luis R. Rodriguez
2017-02-21  7:16       ` Grumbach, Emmanuel
2017-02-21 18:15         ` Luis R. Rodriguez
2017-02-21 20:17           ` Luis R. Rodriguez
2017-02-22  0:18             ` Luis R. Rodriguez
2017-02-22  2:09               ` [PATCH v2 0/2] iwlwifi: corner case fix and request module changes Luis R. Rodriguez
2017-02-22  2:09                 ` Luis R. Rodriguez [this message]
2017-02-22  2:09                 ` [PATCH v2 2/2] iwlwifi: simplify requesting ops module Luis R. Rodriguez
2017-02-22  2:10               ` [PATCH v2 0/2] iwlwifi: share opmode start code Luis R. Rodriguez
2017-02-22  2:10                 ` [PATCH v2 1/2] iwlwifi: share opmode start work code Luis R. Rodriguez
2017-02-22  2:10                 ` [PATCH v2 2/2] iwlwifi: convert final opmode work into a workqueue Luis R. Rodriguez
2017-02-17  2:09 ` [RFC 3/5] iwlwifi: share opmode start work code Luis R. Rodriguez
2017-02-17  2:09 ` [RFC 4/5] iwlwifi: move opmode loading to shared routine Luis R. Rodriguez
2017-02-17  2:09 ` [RFC 5/5] iwlwifi: convert final opmode work into a workqueue Luis R. Rodriguez
2017-03-01  7:12 ` [RFC 0/5] iwlwifi: enhance final opmode work Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170222020939.28140-2-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=emmanuel.grumbach@intel.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linuxwifi@intel.com \
    --cc=luciano.coelho@intel.com \
    --cc=ming.lei@canonical.com \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.