On Mon, Jun 23, 2014 at 11:32 AM, Arik Nemtsov <arik@xxxxxxxxxx> wrote: >> modifieres for user_reg_hint_type, you'd want a driver_reg_hint_type, Minor note, since the driver reg hint type can be require the regulatory data source to be internal to the driver (firmware or driver, we won't know) and since the new API can allow the driver/firmware to pass and let the request come from CRDA / wireless-regdb / internal db the driver hint is different from the final *set* regulatory domain. So for example although the goal was to query firmware first if the driver passed and let the source of regulatory data come from CRDA / wireless-regdb / internal regdb we'd want to ensure userspace is informed of this. So I think we'd need a regulatory data structure source type as well, right now it'd default to wireless-regdb as the source (that would suffice for CRDA or internal-db), and your changes would add an internal-driver source. Since this is allowing drivers to be explicit about their regulatory data it would be nice if as part of this we can then get 'iw reg get' the ability to then spit out per wiphy regd. Since even the custom regd requires passing a custom regd this could even enable parsing that data as well. This should make trouble shooting for intersections much easier on complex systems. 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
