[PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX

[Tamizh chelvam]

Hi Johannes,

Thanks for your comments.

On 2016-12-16 15:07, Johannes Berg wrote:
>> > > is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
>> >
>> > It's not really clear to me what you intend to do this - if it's
>> > really support flags then you really should name those better.
>> >
>> 
>> This is support flags and it used by the driver to intimate driver 
>> supported frame type for the BTCOEX to cfg like
>> "wiphy_wowlan_support_flags" implementation. Please suggest if this
>> is ok ? I will be thankful if you can suggest a  better one if this
>> is not ok "WIPHY_BTCOEX_SUPPORTS_BE"
> 
> Well, I see a few things here:
> 
> 1) does it even make sense to split it out per AC? wouldn't it be weird
> if you supported this only for VO and BK, and not the others, or
> something like that?
> 
It has support for BE, VI, management and beacon frames also.
Or do you meant to say like support only for VO and BK?

> 2) Wouldn't it make more sense to define this in nl80211 and just pass
> the bitmap through to userspace? That would save quite a bit of netlink
> mangling complexity.
> 
Please let me know if the below design/thought is fine to you.

iw phyX set btcoex_priority <[vi, vo, be, bk, mgmt, beacon]>

By this command user should give one or more than one frame types for 
this btcoex priority,
we will parse that in "iw" and send as a single bitmap(less than 0x64) 
to
the driver?

> 3) I think the naming is confusing - "WIPHY_BTCOEX_SUPPORTS_BE_PREF" or
> so might be more appropriate?
> 
If the above suggestion is fine, we may not need these flags.

>> Do you mean to say, sending a value from user space and parse that
>> in  the driver?
> 
> I was more thinking of the capability advertisement, but yeah, both
> ways seems reasonable.
> 
Okay.

Thanks,
Tamizh.