Message-ID: <87wo4usrik.fsf@codeaurora.org>
Date:   Fri, 29 May 2020 18:13:55 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Jérôme Pouiller <jerome.pouiller@...abs.com>
Cc:     devel@...verdev.osuosl.org, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 00/10] staging: wfx: introduce nl80211 vendor extensions

Jérôme Pouiller <jerome.pouiller@...abs.com> writes:

> On Wednesday 27 May 2020 14:34:37 CEST Kalle Valo wrote:
>> Jerome Pouiller <Jerome.Pouiller@...abs.com> writes:
>> 
>> > This series introduces some nl80211 vendor extensions to the wfx driver.
>> >
>> > This series may lead to some discussions:
>> >
>> >   1. Patch 7 allows to change the dynamic PS timeout. I have found
>> >      an API in wext (cfg80211_wext_siwpower()) that do more or less the
>> >      same thing. However, I have not found any equivalent in nl80211. Is it
>> >      expected or this API should be ported to nl80211?
>> 
>> struct wireless_dev::ps_timeout doesn't work for you?
>
> Indeed, cfg80211_wext_siwpower() modify wireless_dev::ps_timeout, but
> there is no equivalent in nl80211, no?

Ah, I remember now. Something like 10 years ago there was a discussion
about using qos-pm framework for modifying the timeout (or something
like that, can't remember the details anymore) but no recollection what
was the end result.

> Else, I choose to not directly change wireless_dev::ps_timeout because I
> worried about interactions with other parts of cfg80211/mac80211.

This is exactly why we have strict rules for nl80211 vendor commands. We
want to have generic interfaces as much as possible, not each driver
coming up with their own interfaces.

>> >   2. The device The device allows to do Packet Traffic Arbitration (PTA or
>> >      also Coex). This feature allows the device to communicate with another
>> >      RF device in order to share the access to the RF. The patch 9 provides
>> >      a way to configure that. However, I think that this chip is not the
>> >      only one to provide this feature. Maybe a standard way to change
>> >      these parameters should be provided?
>> >
>> >   3. For these vendor extensions, I have used the new policy introduced by
>> >      the commit 901bb989185516 ("nl80211: require and validate vendor
>> >      command policy"). However, it seems that my version of 'iw' is not
>> >      able to follow this new policy (it does not pack the netlink
>> >      attributes into a NLA_NESTED). I could develop a tool specifically for
>> >      that API, but it is not very handy. So, in patch 10, I have also
>> >      introduced an API for compatibility with iw. Any comments about this?
>> 
>> If you want the driver out of staging I recommend not adding any vendor
>> commands until the driver is moved to drivers/net/wireless. Also do note
>> that we have special rules for nl80211 vendor commands:
>> 
>> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
>
> I hoped to suggest the move of this driver outside of staging in some
> weeks (the last items in TODO list are either non-essential or easy to
> fix). So, you suggest me to resend these patches after that change?

It makes a lot easier for the review if there are no nl80211 vendor
commands in the driver, most likely you would need to remove them. So
yes, don't add anything unless absolutely essential until the driver is
accepted upstream. The smaller the driver the faster the review.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Powered by blists - more mailing lists