On Tue, Jun 24, 2014 at 09:09:41AM +0300, Arik Nemtsov wrote: > 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. OK. > > 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. OK. 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
