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? > 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. johannes -- 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
