From: Johannes Berg <johannes@sipsolutions.net>
To: Arend van Spriel <arend@broadcom.com>
Cc: "John W. Linville" <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org
Subject: Re: [RFC 2/3] cfg80211: expose cfg80211_disable_40mhz_24ghz module parameter
Date: Wed, 25 Jun 2014 17:57:26 +0200 [thread overview]
Message-ID: <1403711846.4140.16.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <53A9B391.4050602@broadcom.com>
On Tue, 2014-06-24 at 19:21 +0200, Arend van Spriel wrote:
> >> + * @wiphy: The wiphy to check.
> >> + *
> >> + * Return: true is 40MHz is disabled in 2.4G band.
> >> + */
> >> +bool wiphy_is_40mhz_24ghz_disabled(struct wiphy *wiphy);
> >
> > Why should that have a wiphy argument?
>
> It is up to cfg80211 to determine the logic behind the function. It is
> just context supplied by the caller. The fact that it is determined by a
> module parameter is internal cfg80211 stuff.
I just don't really see any way it would ever be per wiphy?
> > Might also be simpler to just export the variable?
>
> Either way is pretty simple I guess.
Yeah, dunno. I guess exporting the function at least makes sure nobody
will try to set the variable, so that's somewhat useful...
I'd prefer to remove the wiphy argument though (and fix the kernel-doc)
johannes
next prev parent reply other threads:[~2014-06-25 15:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 9:16 [RFC 0/3] brcmfmac: provide band info upon wiphy registration Arend van Spriel
2014-06-17 9:16 ` [RFC 1/3] brcmfmac: move attach and detach functions in wl_cfg80211.c Arend van Spriel
2014-06-17 9:16 ` [RFC 2/3] cfg80211: expose cfg80211_disable_40mhz_24ghz module parameter Arend van Spriel
2014-06-23 9:34 ` Johannes Berg
2014-06-24 17:21 ` Arend van Spriel
2014-06-25 15:57 ` Johannes Berg [this message]
2014-06-25 16:50 ` Arend van Spriel
2014-06-17 9:16 ` [RFC 3/3] brcmfmac: update band and regulatory info before wiphy_register() Arend van Spriel
2014-06-23 9:37 ` Johannes Berg
2014-06-24 17:11 ` Arend van Spriel
2014-06-25 15:55 ` Johannes Berg
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=1403711846.4140.16.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arend@broadcom.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/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;
as well as URLs for NNTP newsgroup(s).