[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <576EAC61.1050900@gmail.com>
Date: Sat, 25 Jun 2016 18:08:01 +0200
From: Erik Stromdahl <erik.stromdahl@...il.com>
To: Jouni Malinen <j@...fi>
Cc: johannes@...solutions.net, johannes.berg@...el.com,
kvalo@...eaurora.org, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] mac80211_hwsim: Added vendor echo command
The mac80211_hwsim driver is currently defining the QCA vendor ID
0x001374 for some reason.
Also, all current vendor commands are using the "QCA_" prefix, hence the
reason why I decided to add the new vendor command with the "QCA_"
prefix as well.
Anyway, I understand that you don't want the hwsim driver bloated with
definitions that does not belong there.
Is there any reason why hwsim uses the QCA vendor id?
Perhaps it would be best if the hwsim driver would define its own vendor id?
On 06/24/2016 10:47 PM, Jouni Malinen wrote:
> On Fri, Jun 24, 2016 at 10:13:54AM +0200, Erik Stromdahl wrote:
>> The purpose of the echo command is to provide a test
>> facility for user space programs.
>
>> diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
>> @@ -332,14 +332,16 @@ static const struct ieee80211_rate hwsim_rates[] = {
>> #define QCA_NL80211_SUBCMD_TEST 1
>> +#define QCA_NL80211_SUBCMD_ECHO 2
>
> NAK. That QCA vendor specific value has not been assigned nor have I
> even seen a request to assign such a value.
>
>> enum qca_nl80211_vendor_subcmds {
>> QCA_WLAN_VENDOR_ATTR_TEST = 8,
>> - QCA_WLAN_VENDOR_ATTR_MAX = QCA_WLAN_VENDOR_ATTR_TEST
>> + QCA_WLAN_VENDOR_ATTR_ECHO,
>
> And this vendor attribute value has already been assigned for another
> purpose.
>
> It is no acceptable to pick arbitrary values of identifiers without
> proper request to the owner of the OUI that is used to assign the
> values.
>
> As far as the QCA vendor specific identifiers are concerned, their
> assignment process is described here:
> http://w1.fi/cgit/hostap/plain/src/common/qca-vendor.h
>
> Please do not submit kernel changes that use any unassigned vendor
> identifier or even worse, a value that have already been assigned for a
> completely different purpose.
>
>
Powered by blists - more mailing lists