On Mon, 2007-09-24 at 18:18 -0400, Luis R. Rodriguez wrote: > 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. > Another option here is just speak to the driver in a hardware-agnostic > sense and just let drivers map this out however they want. I guess it > provides for a cleaner API if we keep this in our own structs though. We could, but unless the hardware operates with frequencies like b43 it'll likely need a big switch() statement which doesn't seem too nice. > > > ACK -- but, since cfg80211 *can* be in charge of updating the, either > > > central channel struct, or each driver's channel struct, we can also > > > have it update power restrictions upon regulatory domain change. Same > > > as above. What do you think? > > > > Well, but the driver must actually change the power level and hence it > > must be notified of the change after it has occurred so it is able to > > adjust. > > Only if the new power restrictions makes he current one invalid. Right. > > 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. Also, just providing the hook is much simpler and we can leave it up to drivers to implement this logic. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
