Linux wireless drivers development
 help / color / mirror / Atom feed
From: Luciano Coelho <coelho@ti.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Guy Eilam <guy@wizery.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 1/3] nl80211: Add probe response offload attribute
Date: Wed, 02 Nov 2011 13:54:45 +0200	[thread overview]
Message-ID: <1320234885.6647.14.camel@cumari> (raw)
In-Reply-To: <1320228817.3950.38.camel@jlt3.sipsolutions.net>

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.


  reply	other threads:[~2011-11-02 11:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-22 19:51 [PATCH v2 1/3] nl80211: Add probe response offload attribute Guy Eilam
2011-10-22 20:00 ` Johannes Berg
2011-10-25  6:16 ` Kalle Valo
2011-10-25  7:25   ` Johannes Berg
2011-10-31 10:04 ` Luciano Coelho
2011-11-02 10:13   ` Johannes Berg
2011-11-02 11:54     ` Luciano Coelho [this message]
2011-11-07 14:42 ` Arik Nemtsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1320234885.6647.14.camel@cumari \
    --to=coelho@ti.com \
    --cc=guy@wizery.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox