Thread (16 messages) 16 messages, 4 authors, 2007-09-25

Re: API to regulatory control (1)

From: Luis R. Rodriguez <hidden>
Date: 2007-09-25 16:13:25

On 9/25/07, Johannes Berg [off-list ref] wrote:
On Mon, 2007-09-24 at 18:18 -0400, Luis R. Rodriguez wrote:
quoted
I saw complaints on the z1211 move thread to upstream about large
patches and driver developers not being able to keep up as mac80211 is
a 'moving target'.
It'll always be. Everything in Linux is a moving target. That's the pain
associated with maintaining a driver out of tree. This change in
particular isn't even hard to follow and I'd happily help change all the
drivers that are in tree.
OK fine, lets just move forward but I'll take you up on the offer ;)
quoted
quoted
I don't think I want to call into some cfg80211 call for this, a
specific notifier seems more appropriate.
Well what if cfg80211  generates a notification if a possible conflict
has been found? Is there a need to generate a notification on power
reg changes to the driver besides this?
Well, that'd mean that cfg80211 would need to keep track of the current
power level. I've intentionally made cfg80211 keep track of as few
things as possible so that drivers are free to change things when
necessary without having synchronisation problems. I would prefer if it
stayed this way.
I wasn't thinking of that, but  instead, of the 'loop' cfg80211 would
do upon regulatory change, on all wiphys.
Also, just providing the hook is much simpler and we can leave it up to
drivers to implement this logic.
Hm, the drivers will still call a cfg80211 helper anyway to update its
channel flags/power limits, why not let cfg80211 just do it then in a
loop for all wiphys upon reg change? At the end of the loop for each
wiphy we can call a driver-specific ops->verify_reg().

  Luis
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help