From: Johannes Berg <johannes@sipsolutions.net>
To: IgorMitsyanko <igor.mitsyanko.os@quantenna.com>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH V3] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
Date: Thu, 17 Nov 2016 09:51:03 +0100 [thread overview]
Message-ID: <1479372663.1463.9.camel@sipsolutions.net> (raw)
In-Reply-To: <c6655668-f433-c784-0098-a94a61874e43@quantenna.com> (sfid-20161116_175111_132947_47E19850)
> > > It's probably worth having a discussion about this behaviour
> > > difference - not necessarily in the context of this driver
> > > submission though.
> >
> > Do you mean that default is to allow to dynamically allocate
> > resources (add_interface) for as much interfaces as memory allows,
> > but only use (allow to open) a limited number of them?
Correct, this is how mac80211 works.
> > This seems like unnecessary complication,
Well, I don't really know where this came from. I suspect some types of
mode switching cases could benefit from it, say (completely
constructed) your hardware supports either two AP or two clients, but
not AP+client - then to switch from 2xAP to 2xclient you'd have to
destroy one of the interfaces, since you can't mode-switch both at the
same time.
Also, interfaces that are down (should!) have no runtime impact on the
device whatsoever, so it's just a little bit more software complexity
to handle.
I think there may also be cases of cfg80211 doing partial interface
combination enforcement only on interfaces that are up.
> > I can see only one relevant comment in documentation to "struct
> > ieee80211_iface_combination" that does not clarify what should be
> > the behavior:
Agree, we never thought about it since for mac80211 it was always
obvious, and for other drivers the other way seemed obvious - I only
found out about it after the fact :)
I think the mode-switching I outlined above is a slight advantage to
the mac80211 scheme, so I wouldn't want to switch mac80211 to this
other scheme, risking that being seen as an API/ABI regression.
At the same time, having all drivers behave the same way seems somewhat
useful, but the consequence would be all drivers having to adopt the
mac80211 scheme. I can't say how difficult that would be - might be
more difficult than it seems since you couldn't statically allocate
your interface pointers etc. as you do now.
johannes
next prev parent reply other threads:[~2016-11-17 8:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1478700000-11624-1-git-send-email-igor.mitsyanko.os@quantenna.com>
2016-11-09 14:00 ` [PATCH V3] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets igor.mitsyanko.os
2016-11-14 9:52 ` Johannes Berg
[not found] ` <62102ba6-cae0-f00d-f989-3f2e9ea43d9b@quantenna.com>
2016-11-16 16:50 ` IgorMitsyanko
2016-11-17 8:51 ` Johannes Berg [this message]
2016-11-15 9:06 ` Johannes Berg
2016-11-16 16:47 ` IgorMitsyanko
2016-11-17 7:54 ` Johannes Berg
2016-11-09 15:56 ` [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device Johannes Berg
[not found] ` <2fcb5f28-808e-f296-7e91-e5185e7577c9@quantenna.com>
2016-11-09 21:05 ` Johannes Berg
2016-11-10 14:02 ` IgorMitsyanko
2016-11-11 11:35 ` Johannes Berg
2016-11-14 8:26 ` IgorMitsyanko
2016-11-14 9:40 ` Johannes Berg
2016-11-23 15:25 ` Kalle Valo
2016-11-23 16:45 ` igor.mitsyanko.os
2016-11-23 17:09 ` IgorMitsyanko
2016-11-24 11:59 ` Kalle Valo
2016-11-25 10:16 ` IgorMitsyanko
2016-12-23 15:12 ` igor.mitsyanko.os
2016-12-23 17:47 ` Christian Lamparter
2016-11-22 14:44 ` IgorMitsyanko
2016-11-28 16:34 ` Kyle McMartin
2016-11-28 17:10 ` Oleksij Rempel
2016-11-28 17:33 ` Oleksij Rempel
2016-11-28 19:01 ` IgorMitsyanko
2016-11-29 3:49 ` Oleksij Rempel
2016-11-29 9:10 ` IgorMitsyanko
2016-11-29 9:34 ` Arend Van Spriel
2016-11-29 10:22 ` IgorMitsyanko
2016-11-28 22:07 ` IgorMitsyanko
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=1479372663.1463.9.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=igor.mitsyanko.os@quantenna.com \
--cc=linux-wireless@vger.kernel.org \
/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.