On Mon, Jun 23, 2014 at 9:57 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx> wrote: > 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. Sure I can add a source to the regulatory_request structure. It will have something like CORE, CRDA, INTERNAL_REGDB, DRIVER. > > 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. This would have to wait a bit on my side. Arik -- 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
