All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	"Felix Fietkau" <nbd@nbd.name>,
	"Arend van Spriel" <arend@broadcom.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
Date: Mon, 02 Jan 2017 16:10:44 +0100	[thread overview]
Message-ID: <1483369844.21014.13.camel@sipsolutions.net> (raw)
In-Reply-To: <CACna6rzvvkXBBHrDj4vVgcM0GmzTxM-Bh60nXYOkRH1-2WrWMQ@mail.gmail.com> (sfid-20170102_160558_947240_E0DB4C21)

On Mon, 2017-01-02 at 16:05 +0100, Rafał Miłecki wrote:
> On 2 January 2017 at 15:04, Johannes Berg <johannes@sipsolutions.net>
> wrote:
> > Perhaps a better approach would be to not combine this with wiphy
> > registration, but require drivers that may use this to call a new
> > helper function *before* wiphy registration (and *after* calling
> > set_wiphy_dev()), like e.g.
> > 
> >    ieee80211_read_of_data(wiphy);
> > 
> > (...)

> I just think it may be better to stick to something like
> ieee80211_read_of_freq_limits
> or
> wiphy_read_of_freq_limits

I have no objection to that.

> As you noted this function will be a bit specific because of
> modifying (possibly shared) band channels. At some point we may want
> to add more helpers for other OF properties which won't have extra
> requirements for driver code. Some drivers may want to use them while
> not necessary risking have shared band channels modified.

That makes sense, although at that time we might still wish to have a
common "read it all" with the combined requirements. But we can cross
that bridge when we get to it.

johannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: "Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Martin Blumenstingl"
	<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
	"Felix Fietkau" <nbd-Vt+b4OUoWG0@public.gmane.org>,
	"Arend van Spriel"
	<arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	"Arnd Bergmann" <arnd-r2nGTMty4D4@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Rafał Miłecki" <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Subject: Re: [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
Date: Mon, 02 Jan 2017 16:10:44 +0100	[thread overview]
Message-ID: <1483369844.21014.13.camel@sipsolutions.net> (raw)
In-Reply-To: <CACna6rzvvkXBBHrDj4vVgcM0GmzTxM-Bh60nXYOkRH1-2WrWMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (sfid-20170102_160558_947240_E0DB4C21)

On Mon, 2017-01-02 at 16:05 +0100, Rafał Miłecki wrote:
> On 2 January 2017 at 15:04, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> wrote:
> > Perhaps a better approach would be to not combine this with wiphy
> > registration, but require drivers that may use this to call a new
> > helper function *before* wiphy registration (and *after* calling
> > set_wiphy_dev()), like e.g.
> > 
> >    ieee80211_read_of_data(wiphy);
> > 
> > (...)

> I just think it may be better to stick to something like
> ieee80211_read_of_freq_limits
> or
> wiphy_read_of_freq_limits

I have no objection to that.

> As you noted this function will be a bit specific because of
> modifying (possibly shared) band channels. At some point we may want
> to add more helpers for other OF properties which won't have extra
> requirements for driver code. Some drivers may want to use them while
> not necessary risking have shared band channels modified.

That makes sense, although at that time we might still wish to have a
common "read it all" with the combined requirements. But we can cross
that bridge when we get to it.

johannes

  reply	other threads:[~2017-01-02 15:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-02 13:27 [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call Rafał Miłecki
2017-01-02 13:27 ` Rafał Miłecki
2017-01-02 13:27 ` [PATCH V2 2/3] dt-bindings: document common IEEE 802.11 frequency limit property Rafał Miłecki
2017-01-02 13:27   ` Rafał Miłecki
2017-01-02 13:49   ` Johannes Berg
2017-01-02 13:49     ` Johannes Berg
2017-01-02 13:27 ` [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property Rafał Miłecki
2017-01-02 13:27   ` Rafał Miłecki
2017-01-02 14:04   ` Johannes Berg
2017-01-02 14:04     ` Johannes Berg
2017-01-02 14:09     ` Rafał Miłecki
2017-01-02 14:09       ` Rafał Miłecki
2017-01-02 15:05     ` Rafał Miłecki
2017-01-02 15:05       ` Rafał Miłecki
2017-01-02 15:10       ` Johannes Berg [this message]
2017-01-02 15:10         ` Johannes Berg
2017-01-02 13:38 ` [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call Johannes Berg
2017-01-02 13:38   ` Johannes Berg
2017-01-02 14:05   ` Rafał Miłecki
2017-01-02 14:05     ` Rafał Miłecki
2017-01-02 14:10     ` Johannes Berg
2017-01-02 14:10       ` Johannes Berg
2017-01-02 22:10 ` kbuild test robot
2017-01-02 22:10   ` kbuild test robot
2017-01-08  7:38 ` kbuild test robot
2017-01-08  7:38   ` kbuild test robot

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=1483369844.21014.13.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=arend@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=nbd@nbd.name \
    --cc=rafal@milecki.pl \
    --cc=zajec5@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.