> For our purposes though this is OK though, just wanted to make that
> note, so we keep in mind this *can* potentially be used by other
> wireless foo.
True, but that hopefully won't even try to use this hint :)
> > +/* This has the logic which determines when a new request
> > + * should be ignored. */
> > +static int ignore_request(struct wiphy *wiphy, enum reg_set_by set_by,
> > + const char *alpha2)
> > +{
> > +}
>
> I take it reg_is_valid_request() was just shifted, no changes were made to it
> here?
Actually, I think I made a small change within, replacing a sequence of
if (...) with a switch().
> > +void regulatory_struct_hint(struct ieee80211_regdomain *rd, u32 bands)
>
> I see you changed the return value to void for both routines the driver
> or a subsystem can use, can you elaborate on the kdoc why this is the
> case?
Well, I don't think I should explain in kdoc why there is no return
value, but I think that the return value is pointless on a _hint_, as
we've seen in earlier discussions everybody seems to be confused by it.
Can you cite a use case? When would you ever care what the system did
with your hint?
> > + /*
> > + * ignore hint if anything else set it or if the given
> > + * bands overlap already defined bands
>
> Is the assumption all along here that this is for hardware which registers
> only the channels its hardware is legally capable of? If so can the
> documentation clarify that?
>
> Otherwise it would seem to me if USER already set it we should get the
> intersection. For example when a user plugs in a USB wireless
> card it would not have gotten the chance to have regulatory_hint'd
> first so the user may have already set it and if the driver
> didn't have a reg_notifier() and simply registered all the channels
> upon mac80211 register then the channels the user set will be
> allowed. Also what about when the COUNTRY_IE had set it (remember the
> result of such country IE request may be in an intersection with the
> first driver too, but its ok, we always can trust the result of the
> structure of the last set regdomain)? Again, disregard this comment
> if the answer to the above paragraph is yes.
I'm not sure I understand your concern. The point here is to allow a
driver to tell the core what it thinks the current operating domain is.
How do you define "[what] hardware is legally capable of"? The
assumption is that a driver will use this hint function if it thinks it
knows what the current operating domain is, in terms of frequency ranges
etc. I don't think there's any other assumption here.
> > + new->alpha2[0] = '9';
> > + new->alpha2[1] = '9';
>
> What about cases where the alpha2 can be determined? I know we have no
> such hardware yet and doubt we will though. Or are we just going to
> point those to use the alpha2 call instead?
Yeah, why would hardware tell us what the regdom is if it has alpha2?
This hypothetical hw could also do both, first hint the structs and then
the alpha2, and if crda is installed the alpha2 hint will call out and
update.
> > + new->n_reg_rules = origrules + rd->n_reg_rules;
> > + /* original rules still intact */
> > + memcpy(&new->reg_rules[origrules],
> > + rd->reg_rules,
> > + sizeof(struct ieee80211_reg_rule) * rd->n_reg_rules);
>
> So did this work ? :) Zhu Yi, did you get to test?
No idea :)
> > static void print_rd_rules(const struct ieee80211_regdomain *rd)
> > {
> > @@ -710,7 +780,6 @@ static int __set_regdom(const struct iee
> >
> > /* Tada! */
> > cfg80211_regdomain = rd;
> > - last_request->granted = 1;
>
> What's wrong with this?
Uh, I just removed the whole granted flag since it wasn't ever tested.
Side cleanup.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
