On Thu, Oct 9, 2008 at 8:22 PM, Zhu Yi <yi.zhu@xxxxxxxxx> wrote: > Does below scenario an expected behaviour? > > 0. A system with iwl3945 BG card and iwl4965 AGN card. > 1. insmod iwl3945 -> regulatory_hint(, 99, rd) return 0; > 2. insmod iwl4965 -> regulatory_hint(, 99, rd2) return -EALREADY; > 3. iwl4965 has no A band support! Yeap. We're going with the regulatory domain the first card specified, which we believe would be the built in card. The reason we follow this logic right now is you cannot really be in two different places at the same time. The real correct behavior here, as the comment also indicates, is we should be doing an intersection between the two regulatory domains and I sent a RFC on a some initial code I had to support such intersection. Until that is not merged we just respect first regulatory request. Additionally since each device can still support more channels and since the driver itself may know better than what the wireless core provides you can override information using reg_notifier() (part of the wiphy) and you can be picky so that you can try to respect the user's request REGDOM_SET_BY_USER so that when they want to be *more* compliant you let them. For this reason I advise that if you add a reg_notifier() you only override the information if initiator is not REGDOM_SET_BY_USER but its up to you of course. This is essentially why this regulatory infrastructure allows users to be more compliant. Alternatively you can live with what you have and just let the user change the regulatory domain (iw reg set US) and this can enable more channels should your driver support these channels on the device (registered channels). So you have a few options here, just keep in mind here the goal is to allow the user to help the core be more compliant. By overriding a disable of a channel (if you re-enable it) you are not helping the user do this. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
