Without this you can get a race against udev and userspace daemons
which will try to poke the device even before netdev ops and friends
are available. Device initialization will fail without this.
Cc: [email protected]
Cc: Naveen Singh <[email protected]>
Cc: Wey-Yi Guy <[email protected]>
Cc: Intel Linux Wireless <[email protected]>
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
I'm pretty sure this is correct, I noticed ath6kl followed the same path as
iwmc3200wifi and I spotted a bug on ath6kl with this path.. so I'm pretty damn
sure this bug is also present on iwmc3200wifi. Please test.
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 9 ---------
drivers/net/wireless/iwmc3200wifi/netdev.c | 6 ++++++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/cfg80211.c b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
index ed57e44..2f48f72 100644
--- a/drivers/net/wireless/iwmc3200wifi/cfg80211.c
+++ b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
@@ -837,17 +837,8 @@ struct wireless_dev *iwm_wdev_alloc(int sizeof_bus, struct device *dev)
wdev->wiphy->cipher_suites = cipher_suites;
wdev->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
- ret = wiphy_register(wdev->wiphy);
- if (ret < 0) {
- dev_err(dev, "Couldn't register wiphy device\n");
- goto out_err_register;
- }
-
return wdev;
- out_err_register:
- wiphy_free(wdev->wiphy);
-
out_err_new:
kfree(wdev);
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index 5091d77..731058e 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -145,6 +145,12 @@ void *iwm_if_alloc(int sizeof_bus, struct device *dev,
iwm_init_default_profile(iwm, iwm->umac_profile);
+ ret = wiphy_register(wdev->wiphy);
+ if (ret < 0) {
+ dev_err(dev, "Couldn't register wiphy device\n");
+ goto out_profile;
+ }
+
return iwm;
out_profile:
--
1.7.4.15.g7811d
On Thu, Mar 17, 2011 at 8:10 PM, Luis R. Rodriguez
<[email protected]> wrote:
> Without this you can get a race against udev and userspace daemons
> which will try to poke the device even before netdev ops and friends
> are available. Device initialization will fail without this.
>
> Cc: [email protected]
> Cc: Naveen Singh <[email protected]>
> Cc: Wey-Yi Guy <[email protected]>
> Cc: Intel Linux Wireless <[email protected]>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
Oops sorry, this was supposed to go to Linville.
LUis
On Fri, Mar 18, 2011 at 6:50 AM, John W. Linville
<[email protected]> wrote:
> On Thu, Mar 17, 2011 at 08:11:17PM -0700, Luis R. Rodriguez wrote:
>> On Thu, Mar 17, 2011 at 8:10 PM, Luis R. Rodriguez
>> <[email protected]> wrote:
>> > Without this you can get a race against udev and userspace daemons
>> > which will try to poke the device even before netdev ops and friends
>> > are available. Device initialization will fail without this.
>> >
>> > Cc: [email protected]
>> > Cc: Naveen Singh <[email protected]>
>> > Cc: Wey-Yi Guy <[email protected]>
>> > Cc: Intel Linux Wireless <[email protected]>
>> > Signed-off-by: Luis R. Rodriguez <[email protected]>
>> > ---
>>
>> Oops sorry, this was supposed to go to Linville.
>
> And probably "[RFT]" instead of "[RTF]" too. :-)
Heh yes, sorry been WTF'ing a bit too much lately.
> Does anyone even have this hardware?
On Thu, Mar 17, 2011 at 08:11:17PM -0700, Luis R. Rodriguez wrote:
> On Thu, Mar 17, 2011 at 8:10 PM, Luis R. Rodriguez
> <[email protected]> wrote:
> > Without this you can get a race against udev and userspace daemons
> > which will try to poke the device even before netdev ops and friends
> > are available. Device initialization will fail without this.
> >
> > Cc: [email protected]
> > Cc: Naveen Singh <[email protected]>
> > Cc: Wey-Yi Guy <[email protected]>
> > Cc: Intel Linux Wireless <[email protected]>
> > Signed-off-by: Luis R. Rodriguez <[email protected]>
> > ---
>
> Oops sorry, this was supposed to go to Linville.
And probably "[RFT]" instead of "[RTF]" too. :-)
Does anyone even have this hardware?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
> On Fri, Mar 18, 2011 at 6:50 AM, John W. Linville
>> Does anyone even have this hardware?
So similarly here we can likely hit a case where we hit the double
wiphy_unregister() twice and I think we'd oops. My preference is to
make wiphy_unregister() re-entrant and let us detect when the device
already was unregistered. Johannes?
Luis
On Fri, 18 Mar 2011 10:41:53 -0700, Luis R. Rodriguez wrote:
>> On Fri, Mar 18, 2011 at 6:50 AM, John W. Linville
>>> Does anyone even have this hardware?
I don't think it even exists any more.
> So similarly here we can likely hit a case where we hit the double
> wiphy_unregister() twice and I think we'd oops. My preference is to
> make wiphy_unregister() re-entrant and let us detect when the device
> already was unregistered. Johannes?
I don't like that, it encourages sloppy driver writing. Seriously,
why is it so hard to properly write the code?
You can fail during init, or you can properly deregister, and that's
about it, no?
johannes
On Fri, Mar 18, 2011 at 11:03 AM, Johannes Berg
<[email protected]> wrote:
> On Fri, 18 Mar 2011 10:41:53 -0700, Luis R. Rodriguez wrote:
>>>
>>> On Fri, Mar 18, 2011 at 6:50 AM, John W. Linville
>>>>
>>>> Does anyone even have this hardware?
>
> I don't think it even exists any more.
Can the driver be removed?
>> So similarly here we can likely hit a case where we hit the double
>> wiphy_unregister() twice and I think we'd oops. My preference is to
>> make wiphy_unregister() re-entrant and let us detect when the device
>> already was unregistered. Johannes?
>
> I don't like that, it encourages sloppy driver writing. Seriously,
> why is it so hard to properly write the code?
>
> You can fail during init, or you can properly deregister, and that's
> about it, no?
That's fine too.
Luis