On Mon, Jun 23, 2014 at 9:23 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx> wrote: > > Well there's a default country burned in the FW/NVRAM. In order to get > > this country I send the "99" country code to FW, and it replies with > > the correct country code. Since we need the regulatory settings > > anyway, I didn't want to invent some new API to just get the current > > country code and then request settings for it. > > We could go down that route but IMHO that would complicate things > > needlessly.. Perhaps you have a different suggestion? > > I see, OK the regulatory code is already complex as it is, and I think > we need to be careful avoid being loose on the API and specially be careful > so things are not used in ways they are not documented. > > Getting a information from drivers as to what country is already > programmed in is definitely useful information and the regulatory_hint() > API was designed for this purpose. It seems we want to evolve this API > to handle different sources, in this case the firmware. > > If I understand the goal correctly you want to let the driver tell > cfg80211 of the alpha2 but instead of having cfg08211 query CRDA / > wireless-regdb / internal-db you want to let the driver excercise the > ability to first query the firmware for the regulatory domain data > structure, the firmware then has the right to ignore the request and > then perhaps allow cfg0211 to proceed to query CRDA / wireless-regdb. If Exactly :) > I understand this correctly then I think a capability flag can be pegged > onto a wiphy to describe this modification on behavior for > regulatory_hint(), that is to query firmware first for regulatory data. > You can do this by extending the struct regulatory_request with the > fact that the driver request type is a bit different just as we have > modifieres for user_reg_hint_type, you'd want a driver_reg_hint_type, > we could also then use this to inform userspace of the type of driver > hint passed if sucessful. We already have code to queue the request > and then you'd just have to extend the processing code and have > a special case there to handle calling back to the driver when needed. Sounds good. > > By centralizing the request we could end up using the driver's own > regulatory domain on all registered wiphys that can lack regulatory > information, drivers that issue the same regulatory_hint() alpha2 on > the same wdev might want to -EALREADY as the source would be the same. > > Depending on the return value, as you already programmed, cfg80211 could > follow on to do something (document clearly the return value and their > consequences would be important), either apply the returned struct or > follow on to call wireless-regdb / internel-db, or bail or whatever. Ok. 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
