linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend Van Spriel <arend.vanspriel@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org, "Rob Herring" <robh@kernel.org>
Cc: "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, "Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V5 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
Date: Wed, 4 Jan 2017 11:02:13 +0100	[thread overview]
Message-ID: <202768c7-b305-7eb0-e42e-dfecd5ec7800@broadcom.com> (raw)
In-Reply-To: <d90127bd-6a9e-2773-fdf9-527afdc004a6@gmail.com>

On 4-1-2017 7:20, Rafał Miłecki wrote:
> Hi Rob,
> 
> On 01/03/2017 11:57 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> This new file should be used for properties that apply to all wireless
>> devices.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> V2: Switch to a single ieee80211-freq-limit property that allows
>> specifying
>>     *multiple* ranges. This resolves problem with more complex rules
>> as pointed
>>     by Felx.
>>     Make description implementation agnostic as pointed by Arend.
>>     Rename node to wifi as suggested by Martin.
>> V3: Use more real-life frequencies in the example.
>> V5: Describe hardware design as possible use for this property
>> ---
>>  .../devicetree/bindings/net/wireless/ieee80211.txt   | 20
>> ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> new file mode 100644
>> index 0000000..1c82c16
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> @@ -0,0 +1,20 @@
>> +Common IEEE 802.11 properties
>> +
>> +This provides documentation of common properties that are valid for
>> all wireless
>> +devices.
>> +
>> +Optional properties:
>> + - ieee80211-freq-limit : list of supported frequency ranges in KHz.
>> This can be
>> +    used to specify extra hardware limitations caused by e.g. used
>> antennas
>> +    or power amplifiers.
> 
> Do you find this description sufficient now? I'm not sure how/if I could
> answer
> "Where would this data normally come from?" question.
>
> One vendor may hardcode choice of channels in their PHP web UI.
> Another one may do it in Andoid app.
> OpenWrt so far was describing this limitation on their wiki page.
> 
> It doesn't sound like any valuable info if I understand this correctly.
> We also
> don't describe where to get information about amount o RAM. One may just
> check
> the hardware, one may use vendor firmware, one could check product data
> sheet.
> 
> If I missed the point, could you help me get this?


There is probably no easy answer. DT is used to describe device
properties that are not otherwise discoverable (at least that is my rule
of thumb). So what is the "device" in this context? You may consider
just the chip, but in this case it is combination of the chip and its RF
path that determine the frequency range that it can operate in.
Apparently this was assured in user-space due to lack of a better
option. Having this specified in DT seems a viable option getting rid of
having a particular platform impose a requirement upon user-space.

You could consider these properties global as they are describing the
platform, but again this depends on what you consider the "device". If
you want to do this global you may add a global node for wifi properties
and use references to the device.

Regards,
Arend

      reply	other threads:[~2017-01-04 10:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-03 22:57 [PATCH V5 1/3] dt-bindings: document common IEEE 802.11 frequency limit property Rafał Miłecki
2017-01-03 22:57 ` [PATCH V5 2/3] cfg80211: move function checking range fit to util.c Rafał Miłecki
2017-01-03 22:57 ` [PATCH V5 3/3] cfg80211: support ieee80211-freq-limit DT property Rafał Miłecki
2017-01-04 13:26   ` Johannes Berg
2017-01-04 16:13     ` Rafał Miłecki
2017-01-05 11:50       ` Johannes Berg
2017-01-03 22:57 ` [PATCH V5 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits Rafał Miłecki
2017-01-04 14:20   ` Rob Herring
2017-01-04  6:20 ` [PATCH V5 1/3] dt-bindings: document common IEEE 802.11 frequency limit property Rafał Miłecki
2017-01-04 10:02   ` Arend Van Spriel [this message]

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=202768c7-b305-7eb0-e42e-dfecd5ec7800@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=arend@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=nbd@nbd.name \
    --cc=rafal@milecki.pl \
    --cc=robh@kernel.org \
    --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 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).