Prev: procfs: Kill the bkl in ioctl
Next: Setting up KGDB environment on MIPS Processor.
From: Holger Schurig on 30 Mar 2010 02:50
> The libertas driver calls wiphy_unregister() without a prior
> wiphy_register() when a devices fails initialization. Fix this by
> introducing a private flag.

Nice.

However, I wonder: do we really need a private variable? Does each driver
introduce a private variable for this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Holger Schurig on 30 Mar 2010 05:50
> If there's any better solution, I'd happily test it.

Not from me, unfortunately. I'm not really interested into getting full
cfg80211 into Libertas. That is, until either _one_ of this two options
happen:

* someone that actually uses/wants the proprietary Libertas mesh steps
forward and says "We'll look after this and make it work with cfg80211"
* we remove the proprietary Libertas mesh support

That is: I won't work on Libertas mesh. I can't justify this time investment
with my employer for something that I'll never need. For my device, my own
version of Libertas + cfg80211 (without any WEXT anymore) works quite nice.


So, if neither of the above things happens, then Libertas will work for the
rest of the world with WEXT, as it did before.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Holger Schurig on 30 Mar 2010 07:00
> I don't get your point. The patch I submitted fixes an Ooops in the
> driver, due to wrong handling of an API. What does that have to do with
> principle discussions about the frameworks in use?

I asked if there is a better method, and you said that you would test a better
solution. That means that someone else should make a better solution.

I just pointed out that I won't be the one who creates the better solution,
because for fundamental reasons I don't see the libertas+cfg80211 approach
going forward. That issue has nothing to do with you or your patch, so please
don't feel offended or confused.


Basically, I neither ack nor nak you patch. Given that it fixes an oops the
patch should go in, and probably to stable at well. I just gave a hint, to
make you think if you could come up with something better.



BTW, testing/fixing of failure paths in libertas as well as simplifying the
call sequence of functions during initialisation could be quite useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Holger Schurig on 9 Apr 2010 10:00
> Ping?

Pong.

I'm a bit swamped with other stuff, so I can't do that right now. That's the
pity of someone who can only use this-and-then on kernel projects.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: procfs: Kill the bkl in ioctl
Next: Setting up KGDB environment on MIPS Processor.