From: Ashok Raj Nagarajan <arnagara@codeaurora.org>
To: Ben Greear <greearb@candelatech.com>
Cc: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>,
linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
ath10k@lists.infradead.org
Subject: Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
Date: Wed, 01 Feb 2017 23:27:18 +0530 [thread overview]
Message-ID: <1f3a3dec67fbe4f580750eb06f9b628b@codeaurora.org> (raw)
In-Reply-To: <2b68dc12-44bf-f510-339a-3d987a88e8b5@candelatech.com>
On 2017-02-01 23:06, Ben Greear wrote:
> On 02/01/2017 09:27 AM, Ashok Raj Nagarajan wrote:
>
>>>> +static int nl80211_parse_sta_txpower_setting(struct genl_info
>>>> *info,
>>>> + struct station_parameters *params)
>>>> +{
>>>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>>>> + enum nl80211_tx_power_setting type;
>>>> + int idx;
>>>> +
>>>> + if (!rdev->ops->set_tx_power ||
>>>> + !wiphy_ext_feature_isset(&rdev->wiphy,
>>>> + NL80211_EXT_FEATURE_STA_TX_PWR))
>>>> + return -EOPNOTSUPP;
>>>
>>> Maybe always let a user set to default value even if the driver does
>>> not
>>> support setting specific values?
>>>
>>
>> IMHO, having some default value in place of non-valid values may not
>> be the right way.
>
> If a user or user-space script wants to always be able to initialize
> things to default
> values, it would be nice if it did not have to pay specific attention
> to whether the
> NIC supports STA_TX_PWR feature or not. Since a NIC that does not
> support this feature will always
> have sta TX power set to default by definition, that is why I think
> you should let
> the call succeed in that case.
>
I think it would be better/easier to handle the error cases in the
user-space scripts than at the driver here, no? NIC that doesn't support
this feature will set the tx power to the station depending on the rate
algorithm in place. So the same NIC and same station will have different
txpower depending on the environment? On the other hand, how do we
decide what constant (?) default value to be sent to userspace?
Thanks,
Ashok
> Thanks,
> Ben
next prev parent reply other threads:[~2017-02-01 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 18:41 [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated Ashok Raj Nagarajan
2017-01-31 18:41 ` [PATCH v2 2/2] mac80211: store tx power value from user to station Ashok Raj Nagarajan
2017-01-31 19:00 ` Ben Greear
2017-02-01 17:29 ` Ashok Raj Nagarajan
2017-02-01 17:32 ` Ben Greear
2017-02-01 17:47 ` Ashok Raj Nagarajan
2017-01-31 19:06 ` [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated Ben Greear
2017-02-01 17:27 ` Ashok Raj Nagarajan
2017-02-01 17:36 ` Ben Greear
2017-02-01 17:57 ` Ashok Raj Nagarajan [this message]
2017-02-01 18:08 ` Ben Greear
2017-02-06 14:38 ` 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=1f3a3dec67fbe4f580750eb06f9b628b@codeaurora.org \
--to=arnagara@codeaurora.org \
--cc=arnagara@qti.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.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;
as well as URLs for NNTP newsgroup(s).