diff options
author | Christian Lamparter <chunkeey@googlemail.com> | 2012-12-22 03:35:24 (GMT) |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2013-01-02 19:38:25 (GMT) |
commit | 6c653f66772c39c5e25db715bbd4730596fccd9e (patch) | |
tree | a087fa5ce595f4996d765b364043f77d21883a9a /tools/firewire | |
parent | 4c3de5920c486b8eefa6187ee6a181864c161100 (diff) | |
download | linux-6c653f66772c39c5e25db715bbd4730596fccd9e.tar.xz |
carl9170: fix -EINVAL bailout during init with !CONFIG_MAC80211_MESH
Sean reported that as of 3.7, his AR9170 device no longer works
because the driver fails during initialization. He noted this
is due to:
"In carl9170/fw.c, ar->hw->wiphy is tagged with
NL80211_IFTYPE_MESH_POINT support if the firmware has Content
after Beacon Queuing. This is both in interface_modes and the
only iface_combinations entry.
If CONFIG_MAC80211_MESH is not set, ieee80211_register_hw
removes NL80211_IFTYPE_MESH_POINT from interface_modes, but
not iface_combinations.
wiphy_register then checks to see if every interface type in
every interface combination is in interface_modes.
NL80211_IFTYPE_MESH_POINT was removed, so you get a WARN_ON
warning and it returns -EINVAL, giving up."
Unfortunately, the iface_combination (types) feature bitmap
in ieee80211_iface_limit is part of a const member in the
ieee80211_iface_combination struct. Hence, the MESH_POINT
feature flag can't be masked by wiphy_register in the
same way as interface_modes in ieee80211_register_hw.
Cc: <stable@vger.kernel.org>
Reported-by: Sean Patrick Santos <quantheory@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Tested-by: Sean Patrick Santos <quantheory@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'tools/firewire')
0 files changed, 0 insertions, 0 deletions