Prev: [PATCH 03/15] x86 acpi/irq: pci device dev->irq is an isa irq not a gsi
Next: [PATCH 02/14] mm,migration: Do not try to migrate unmapped anonymous pages
From: Daniel Mack on 30 Mar 2010 05:00
On Tue, Mar 30, 2010 at 08:49:07AM +0200, Holger Schurig wrote:
> > 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?

I didn't check other drivers thoroughly. I just saw the comment on the
function which does the wiphy allocation and considered libertas to be
special in the way it deals with the wireless core:

/*
* At this time lbs_private *priv doesn't even exist, so we just allocate
* memory and don't initialize the wiphy further. This is postponed until we
* can talk to the firmware and happens at registration time in
* lbs_cfg_wiphy_register().
*/

And as I didn't find any function to tell me whether a wiphy has been
registered and not just allocated, I saw no other way than manually
track what the libertas driver does.

If there's any better solution, I'd happily test it.

Thanks,
Daniel

--
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: Daniel Mack on 30 Mar 2010 07:00
On Tue, Mar 30, 2010 at 11:49:13AM +0200, Holger Schurig wrote:
> > 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.

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?

Daniel

--
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: Dan Williams on 30 Mar 2010 13:20
On Tue, 2010-03-30 at 12:59 +0200, Holger Schurig wrote:
> > 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.

Fine; just rip out the mesh code and do the vanilla cfg80211 conversion
for infra & adhoc, and we'll add the mesh code back later. I don't have
time to do the cfg80211 bits, neither do the OLPC guys (AFAIK), so lets
take advantage of your willingness to do this and just move the driver
forward.

Dan

>
> 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.
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev


--
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: [PATCH 03/15] x86 acpi/irq: pci device dev->irq is an isa irq not a gsi
Next: [PATCH 02/14] mm,migration: Do not try to migrate unmapped anonymous pages