On Wed, 2011-11-02 at 11:13 +0100, Johannes Berg wrote: > On Mon, 2011-10-31 at 12:04 +0200, Luciano Coelho wrote: > > > > + * @NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT: Indicates the support > > > + * of probe response offloading by the driver/firmware. > > > + * In addition this attribute holds a bitmap of the supported protocols > > > + * for offloading using &enum nl80211_probe_resp_offload_support_attr. > > > + * > > > I'm not sure I understand why we need this. Why aren't the flags > > themselves enough? > > Not sure I understand the question? It was what I meant (and you answered) below. :) > > Johannes wrote, on a separate thread: > > > Oh, and probably a regular WIPHY flag that indicates whether the > > > attribute should be added at all so that it can also be 0 but present > > > (presence with 0 value indicates something other than not present). > > > > What would be the meaning when the WIPHY flag is set but the attributes > > are all 0? Wouldn't it mean that we don't support probe_resp offload at > > all? Or would it mean that we support probe_resp offloading in normal > > cases (ie. not WCS nor P2P)? If the latter is the case, why not add a > > bit in the attributes to indicate that "normal" probe_resp offloading is > > supported? I think this would be cleaner because there wouldn't be any > > implicit semantics. > > It would mean we don't support probe response offload at all, and as a > consequence would be more or less equivalent to having 0xfffffff as the > flags mask (everything is "supported"). > > Adding a flag for "normal" doesn't make sense: you can only ever reply > to "normal" probe requests, you need to send any "special" ones up to > the host. So each bit in this bitfield essentially says "I support this > by passing it to the host" -- a bit for "normal" doesn't make sense in > that context. Okay, I get it now. So the flags are actually telling which types of probe responses the hardware can pass up to the host when probe_resp offload is in use. My confusion was because I thought the flags were actually telling which type of probe_resps the HW could offload. Thanks for clarifying. -- Cheers, Luca. -- 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
